Third-Party Cloud Access Review: What the Northflank Breach Says About Vendor Roles in Your Cloud

On 30 October 2026, the developer platform Northflank told its customers something no platform team wants to read: “Assume all environment variables have been decrypted. Disable/rotate all keys.” Within hours, customers were reporting that AI API keys stored on the platform had been used by someone else. Rotation is the right first move. But rotation only covers the secrets you put into a vendor. It says nothing about the access a vendor holds into you. That second list is what a third-party cloud access review produces, and for most organisations it does not exist until an incident forces someone to build it by hand.

This is a practical, Tuesday-style walkthrough: what happened, why vendor-held access is a different problem from vendor-held secrets, and how to run the review in an afternoon, with or without CloudShieldSecure.

What happened at Northflank

According to Northflank’s public status page and the timelines reconstructed from it:

• 30 October, 11:43 UTC — a threat alert from Wiz reached Northflank. Network-policy patches followed from 12:02 UTC.
• 13:58 UTC — the status moved to “Identified”, with the instruction to assume all environment variables had been decrypted and to rotate all keys.
• Same day — “Multiple users are confirming that their AI keys have been used.” Northflank rolled out one-click secret rotation for its managed Postgres and MongoDB add-ons, then MySQL, Redis, MinIO and RabbitMQ over the following day, and enabled audit logs for all customers, including free tier.
• 2 November — Northflank’s update points to secrets held in its control plane, says running workloads were unaffected and dedicated or forward-deployed control planes were out of scope, and reports that it revoked access tokens, sessions, VCS integrations and cross-account IAM roles where it could. It also says it patched a separate Linux vulnerability, CVE-2026-98432, across its fleet including connected bring-your-own-cloud (BYOC) clusters, without saying that bug was the way in.

What is not known yet: the root cause, the exposure window, the number of affected customers, or the attacker. Northflank has promised a root-cause analysis. Until it lands, treat every statement above as the vendor’s own finding, not as independent assurance.

Two lists, not one

Most incident guidance after a platform breach is about the first list: secrets you handed the vendor. Database passwords, AI provider keys, payment API tokens, anything you typed into an environment-variable field. That list is painful but tractable. You rotate, you check provider usage logs for the days before the incident, and you set spend caps on AI keys, because a stolen LLM key is monetised within hours.

The second list is quieter: identities the vendor can use inside your cloud. A modern PaaS often needs to create load balancers, pull images, or manage clusters in your own AWS, Google Cloud or Azure account. That access usually takes one of three shapes:

1. A cross-account IAM role in your AWS account whose trust policy names the vendor’s AWS account as a principal.
2. A workload identity federation pool or federated credential in Google Cloud or Microsoft Entra ID that trusts tokens issued by the vendor’s identity provider.
3. A long-lived access key or service-account key you created for the vendor and pasted into its dashboard, which is the worst of both worlds: it sits on list one and list two.

Northflank revoking cross-account roles from its side is helpful. It does not remove the role from your account. The trust relationship, and whatever permissions it grants, stay in place until you change them.

Why this matters at scale

Tenable’s Cloud and AI Security Risk Report 2026 found that 53% of organisations have given third parties access to internal systems via external accounts, and that 14% expose over 75% of their total cloud resources to trusted third parties. A vendor security questionnaire measures the vendor’s controls. Nobody’s questionnaire measures what fraction of your estate that vendor can reach. They are different numbers, and only the second one changes when the vendor is breached.

AWS’s own guidance on third-party roles is clear about the guard rail that matters most: require an external ID in the trust policy. AWS says the external ID’s primary function is to prevent the confused deputy problem, that it should be generated by the third party, and that it is not a secret. AWS also reminds you that third parties “can access any resource that you specify in the policy” and that “their use of your resources is billed to you”.

This is not the first vendor-identity incident this season. Our ConnectWise Cloud Backup / Storm-0940 analysis covered the Microsoft 365 version of the same problem: an app identity you had already consented to, used by someone else.

Running a third-party cloud access review

The review answers four questions for every external principal: who is it, what can it reach, when did it last act, and is the trust bounded?

Step 1: Inventory external principals

On AWS, IAM Access Analyzer with an account- or organisation-level analyzer lists roles and resources that are shareable outside your zone of trust:

aws accessanalyzer list-analyzers
aws accessanalyzer create-analyzer --analyzer-name external-access --type ACCOUNT   # if none exists
aws accessanalyzer list-findings --analyzer-arn <analyzer-arn> \
  --filter '{"resourceType": {"eq": ["AWS::IAM::Role"]}, "status": {"eq": ["ACTIVE"]}}'

For a quick manual pass, dump every role’s trust policy and look for account IDs that are not yours:

aws iam list-roles --query 'Roles[].{Role:RoleName,Trust:AssumeRolePolicyDocument.Statement[].Principal}' --output json

On Google Cloud, list workload identity pools and their providers (gcloud iam workload-identity-pools list --location=global). In Entra ID, review federated credentials on app registrations (az ad app federated-credential list --id <app-id>) alongside enterprise apps with consented permissions.

Step 2: Map each principal to a named vendor and an owner

Every external account ID should resolve to a vendor name and an internal owner. Unknown account IDs are findings in their own right. So are roles for vendors you stopped using.

Step 3: Check what each one can reach, and when it last acted

aws iam get-role --role-name <role> --query 'Role.RoleLastUsed'
aws iam list-attached-role-policies --role-name <role>

A vendor role with AdministratorAccess that has not been used in 90 days is a standing liability with no business benefit. For any vendor that is currently in an incident, pull CloudTrail AssumeRole events for that role over the exposure window and compare source IPs against the vendor’s published ranges.

Step 4: Check that trust is bounded

For every cross-account trust, confirm there is an sts:ExternalId condition. Where the vendor supports it, narrow permissions to the services it actually manages. For federation, confirm the attribute conditions pin the trust to your tenant or project on the vendor side, not to any token the vendor’s issuer signs.

The CloudShieldSecure perspective

At CloudKonsult we built CloudShieldSecure on the premise that cloud risk is a question of reach, not a count of findings. For a vendor incident, that means the useful view is per vendor: every principal that vendor controls in your accounts, the permissions behind it, its last activity, and whether the trust has guard rails. CloudShieldSecure assembles that view across AWS, Google Cloud and Azure identities, flags trusts with no external ID or condition, and highlights long-lived keys held by external platforms, so the second list exists before the incident rather than being rebuilt during it.

The same view helps on list one. Knowing which cloud keys were created for a vendor tells you exactly which ones need rotating when that vendor posts a status update like Northflank’s. You can see how this works at cloudshieldsecure.cloudkonsult.cloud.

Recommended actions

1. If you use Northflank: rotate every secret held there, starting with AI provider keys and cloud credentials; check provider usage logs from before 30 October; set spend limits on AI keys.
2. Then, for every PaaS and SaaS vendor: run Steps 1–4 above. Remove trusts for vendors you no longer use.
3. Replace long-lived keys held by vendors with role assumption or federation wherever the vendor supports it.
4. Require an external ID on every third-party AWS trust policy, generated by the vendor.
5. Make the review recurring. A quarterly third-party cloud access review is cheaper than one rebuilt under incident pressure.
6. Watch for Northflank’s root-cause analysis and re-check your exposure window once it is published.

Sources & references

• Northflank status page
• Qovery — timeline of the Northflank incident
• DEV Community — summary of Northflank’s 2 November update
• AWS IAM — Access to AWS accounts owned by third parties
• AWS IAM — The confused deputy problem
• Tenable — Cloud and AI Security Risk Report 2026