BYOC vendor access needs federation, not standing cloud keys

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: BYOC vendor access should move away from standing cloud keys because long-lived credentials create avoidable exposure, scope drift and revocation problems.

Why it matters: IAM, PAM and NHI teams need a clearer access model for vendor-operated workloads because the trust relationship has to be auditable, time-bound and removable without waiting on manual key rotation.

Context

Bring-your-own-cloud changes vendor access from a perimeter question into an identity question. The vendor is operating inside the customer's cloud account, so the security problem is no longer whether access exists but whether it is scoped, time-limited and revocable without creating standing privilege. NHI lifecycle management becomes the baseline because the access path now has a lifecycle of its own.

The core failure mode is familiar: a vendor identity is granted more privilege than the workload needs, then left in place long after the operational need has changed. That is a governance problem first and a cloud problem second, because entitlement drift is what turns a temporary integration into a durable exposure.

The article's model is strongest when it separates durable trust from durable secrets. A vendor can operate legitimately inside a customer environment, but the access relationship still needs to be engineered like any other privileged identity with explicit ownership, review and retirement.

Key questions

Q: How should teams govern vendor access in BYOC environments?

A: Teams should govern BYOC vendor access as a full identity lifecycle, not a one-time integration. That means assigning ownership, limiting the role to the exact workload, setting expiry and revocation conditions, and ensuring the customer can remove access without waiting for vendor-side action. The safest pattern is scoped, auditable and time-bound access with clear offboarding.

Q: Why do long-lived access keys increase risk in cloud environments?

A: Long-lived keys create standing access that is easy to reuse, hard to govern, and difficult to revoke at scale. If they are embedded in code or shared across teams, compromise can lead to broad access that persists until manually cleaned up. Temporary roles and federated identity reduce exposure and make access far easier to control.

Q: How does workload identity federation work in Microsoft Entra ID?

A: Workload identity federation in Microsoft Entra ID lets an external workload exchange a trusted external token for an Entra access token without a stored secret. You configure a federated trust between the Entra application and the external issuer, then the workload presents its asserted identity at runtime. Monitor who can create trusts, limit claims, and apply least privilege to the app registration.

Q: What is the difference between cross-account roles and federated credentials?

A: Cross-account roles are permissions in one cloud account that can be assumed by a principal from another account, usually through a trust policy and temporary credentials. Federated credentials let an external identity provider authenticate a human or workload and exchange that trust for short-lived access, often via SAML or OIDC. The first is account-to-account delegation, the second is identity federation.

Technical breakdown

Why standing credentials fail in BYOC integrations

Standing credentials create a permanent bearer instrument inside a customer account. If a vendor stores an IAM user key, that secret can be copied, leaked, forgotten or silently over-scoped, and the customer has no native lifecycle visibility into when the trust should end. The real issue is not only credential theft. It is that the access path persists independently of the workload that justified it, so the privilege survives staff changes, deployment changes and incident response delays. See the NHI Lifecycle Management Guide.

Practical implication: Treat any vendor-held long-lived cloud key as an exception that requires explicit retirement criteria, not an acceptable default.

How cross-account roles reduce, but do not remove, trust risk

Cross-account roles replace a static secret with temporary credentials issued through STS. That removes the vendor-side long-lived key, but it still leaves a standing trust relationship in the customer account, anchored by the role policy, external ID and scope of allowed actions. In practice, the security boundary shifts from secret custody to trust-policy precision. If the role trusts the wrong principal or grants broad permissions, the model still allows excessive access, only through a cleaner mechanism. See the Privileged Access Management Guide.

Practical implication: Pin the trust policy to a specific vendor role and scope the role permissions to the exact resources and actions required.

Why federated short-lived credentials are the target state

Federated credentials bind access to a cryptographic workload identity rather than a reusable shared secret. The customer cloud validates a signed token from the vendor's identity provider and issues short-lived credentials only for that subject, which improves traceability and reduces the chance of secret reuse across tenants. This pattern is stronger because the access proof is minted at request time and can be narrowed to a single workload, namespace or service account. It is the closest fit to zero standing privilege for machine-to-machine vendor access.

Practical implication: Prefer federation where the vendor can prove workload identity directly and avoid any design that requires a reusable secret.

Threat narrative

Attacker objective: The objective is durable access to customer cloud resources through a vendor trust path that outlives the legitimate operational need.

1. Entry occurs when a vendor is granted a long-lived IAM user, cross-account role or federated trust path into the customer's cloud environment.
2. Credential abuse follows when that access is copied, leaked, over-scoped or retained after the original operational need has ended.
3. Escalation happens when policy drift or broad permissions let the vendor identity touch resources beyond its intended workload boundary.
4. Impact is unauthorized access to customer cloud assets, with the blast radius determined by how much privilege the vendor identity accumulated.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

BYOC access is now a lifecycle problem, not just a policy problem. The article's core point is that vendor-operated software inside customer cloud accounts needs explicit ownership from grant to revocation. A trust relationship that is never reviewed eventually behaves like standing privilege, even when it began as a temporary integration. Practitioners should govern vendor access as a managed identity lifecycle, not a one-time onboarding event.

Standing secrets are the wrong primitive for customer-cloud operation. A long-lived access key turns vendor access into a secret custody problem, which is brittle across turnover, breach response and policy drift. The stronger pattern is not better storage of the same secret but eliminating the shared secret entirely wherever the workload can present its own identity. That is the practical distinction between a credential that can be copied and a credential that is minted per session.

Least privilege only works if the scope is mechanically narrow. The article's examples show that a broad trust policy can erase the benefit of short-lived credentials. Even a temporary role becomes a standing liability if it can reach whole accounts, wildcard services or unrelated tenant data. The practitioner lesson is that privilege precision matters more than the token format itself.

Vendor access without lifecycle offboarding: The governance assumption is that a customer can safely leave vendor access in place and manage risk later through rotation or occasional review. That assumption fails when the vendor relationship changes faster than the access path, because the entitlement can survive the operational need that justified it. The implication is that revocation and ownership transfer must be designed into the access model from the start.

Trusted execution does not equal trusted scope. A workload can authenticate cleanly and still be given far too much authority once it arrives. That is why federated identity should be judged by the permissions attached to the resulting role, not by the elegance of the federation flow itself. Security teams should assess the trust boundary after authentication, where authorization actually begins.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• More than 95% of infrastructure-as-a-service accounts use less than 3% of the entitlements they are granted, according to Gartner.
• Read next: Privileged Access Management Guide

What this signals

Least privilege for vendor access now hinges on identity path design, not just policy text. When a customer accepts a reusable key, the control is already weaker than the audit trail suggests. The better model is per-workload federation with narrow permissions and a revocation path that does not depend on another organisation's ticket queue.

Vendor access without offboarding creates identity debt. A cloud role that persists after the integration changes is functionally the same as a dormant privileged account, even if it was issued for a valid purpose. Practitioners should expect more BYOC reviews to focus on who can revoke access, how fast that revocation happens and whether the trust relationship can be isolated per tenant.

Privilege precision is becoming the deciding control for third-party cloud access. 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. In BYOC patterns, that means the next governance question is not whether the vendor is trusted, but whether the trust scope is mechanically bounded to one workload and one purpose.

For practitioners

• Define vendor access as a revocable identity relationship Assign each vendor workload a named owner, expiry condition and revocation path so the access ends when the operational need ends.
• Replace shared secrets with federated workload identity Use OIDC or workload identity federation where the vendor can prove the calling workload cryptographically instead of storing a reusable cloud key.
• Scope every vendor role to one capability Separate ingestion, transformation, support and write-back into different roles so no single vendor identity can act across unrelated functions.
• Audit trust policies for wildcard access Review each vendor role for explicit resource ARNs, narrow actions and constrained principals, then remove account-wide trust and wildcard permissions.
• Make human support access just-in-time Treat diagnostic access by vendor support staff as an approval-gated exception with a short duration and visible session record.

Key takeaways

• BYOC vendor access fails when a temporary integration is treated like a durable entitlement, because the access path then outlives the business purpose.
• The strongest pattern is federated, short-lived access tied to a specific workload identity and a narrowly scoped role.
• Practitioners should focus on offboarding, trust-policy precision and revocation speed, because those controls determine whether vendor access stays bounded.

Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Privileged Access Management Guide · AI Agent Authorisation Guide · Third-Party, B2B and Contractor Access Guide

Key terms

• Bring Your Own Cloud: A deployment model where software runs inside the customer’s cloud account rather than the vendor’s environment. It gives the customer stronger control over data residency, operational boundaries, and access decisions, while forcing the vendor to support the application through explicitly governed cross-boundary workflows.
• Cross-Account IAM Role: A cross-account IAM role is an access relationship that allows one cloud account or identity to assume permissions in another account. These roles are useful for legitimate integrations, but they also create risk when privileges are excessive, trust is too broad, or monitoring cannot trace how access is used.
• OIDC Federation: OIDC federation is a token-based trust model that lets one system accept identity assertions from another. It is commonly used to avoid static cross-environment credentials and to issue short-lived access based on trusted token claims. The control value depends on how tightly the trust relationships are governed.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.