AWS IAM Roles Anywhere exposes hidden NHI trust gaps

At a glance

What this is: AWS IAM Roles Anywhere lets external workloads authenticate to AWS with certificates, but the article shows how trust anchors, revocation handling, and role mapping can create hidden NHI access paths.

Why it matters: IAM and security teams need to treat certificate-based workload access as a governed identity lifecycle, because broad trust and stale revocation can quietly expand blast radius across cloud and data systems.

By the numbers:

• 72% of identity professionals find machine identities more challenging to manage than human identities, citing poor internal processes and insufficient tooling.
• Only 38% have automated certificate lifecycle management in place.
• 57% of organisations lack a complete inventory of their machine identities.
• 66% of identity experts perceive machine identities as posing higher security risks than human identities.

👉 Read Veza's analysis of AWS IAM Roles Anywhere NHI governance risks

Context

AWS IAM Roles Anywhere extends certificate-based authentication to external workloads, which makes the certificate itself part of the identity boundary. The governance problem starts when trust anchors, certificate revocation, and role mapping are managed as isolated AWS settings instead of as one lifecycle-controlled access model for non-human identities.

For IAM teams, the core issue is not whether certificates can authenticate a workload. It is whether the organisation can prove which workload owns the certificate, which role it can assume, and whether revoked or forgotten certificates still map to real permissions. That is a classic NHI governance problem, not just an AWS configuration detail.

The article’s starting position is typical for cloud environments that have adopted workload certificates without mature attribution and offboarding controls. Once certificate issuance becomes easy, inventory and revocation discipline become the deciding factors in whether access remains governed or turns into orphaned privilege.

Key questions

Q: What breaks when certificate revocation is not enforced for external workload identities?

A: A revoked certificate can continue to authenticate if revocation checks are stale or incomplete, which turns a cut-off control into a paper exercise. The workload may keep assuming roles and reaching sensitive AWS resources long after operators believe access has ended. That is why revocation must be tested in the live access path, not just recorded in policy.

Q: Why do certificate-based workload identities increase cloud governance risk?

A: They increase risk when trust anchors are broad, ownership is unclear, and role mappings are more permissive than the workload needs. In that setup, authentication succeeds even when the effective privilege surface is oversized. The result is hidden NHI access that is hard to inventory, review, and remove cleanly.

Q: How do security teams know if Roles Anywhere profiles are too permissive?

A: They are too permissive when the certificate can assume roles that reach data or services unrelated to the workload's documented function. Look for broad profile matching, shared trust anchors, and role assumptions that cannot be tied to a specific business service. If the access path cannot be explained in one sentence, it is probably too broad.

Q: Who should be accountable for orphaned certificate-based access?

A: The accountable owner should be the team that owns the workload, the CA, and the revocation process together. If those responsibilities are split, orphaned certificates can remain active after systems are retired or vendors change. Accountability has to follow the lifecycle of the identity, not just the infrastructure it runs on.

Technical breakdown

Certificate trust anchors and workload attribution

AWS IAM Roles Anywhere uses a certificate authority as a trust anchor, which means any certificate chained to that CA can be accepted if the policy match succeeds. That creates a broad trust domain unless certificate issuance is tightly bounded to known workloads and owners. If the certificate is not linked back to a specific system, team, or lifecycle state, the identity becomes portable privilege rather than governed workload identity. The security issue is less about the certificate format and more about how far trust extends from the CA into AWS authorization.

Practical implication: constrain certificate issuance to named workloads and require ownership metadata that survives through revocation and offboarding.

Revocation lists and stale certificate acceptance

Certificate revocation only works when the revocation list is current and actually consulted in the access path. If CRLs are stale or poorly integrated, a revoked certificate may continue to authenticate, which turns revocation into a delayed control instead of a real cut-off. In a workload identity model, that gap matters because machines do not age out on their own. Forgotten systems, abandoned pipelines, and compromised certificates can keep working long after the operator believes access ended.

Practical implication: validate CRL freshness and monitor for revoked certificates that still map to active AWS access.

Role profiles and effective privilege expansion

In Roles Anywhere, the certificate does not directly grant data access. It assumes a role, and that role profile determines the real blast radius. If certificate matching is loose and role mappings are broad, the workload can inherit more privilege than the certificate owner intended. This is where NHI governance becomes visible: entitlement scope, not just authentication success, determines whether the workload can touch S3, KMS, EC2, or downstream datasets. Effective privilege must be judged by the end-to-end path from certificate to permissions.

Practical implication: review every certificate-to-role mapping for excess privilege and remove profiles that can assume broader access than the workload needs.

Threat narrative

Attacker objective: The objective is to turn certificate-based workload trust into durable access to sensitive AWS resources without being clearly attributable.

1. Entry occurs when an external workload presents a certificate issued by a broadly trusted CA, allowing it to authenticate into AWS Roles Anywhere.
2. Escalation occurs when the certificate is mapped to an over-permissive role profile or when a revoked certificate still remains valid because revocation control is stale.
3. Impact occurs when the hidden non-human identity can reach customer PII or other sensitive AWS resources through inherited permissions.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Broad certificate trust is an identity boundary problem, not just an AWS feature choice. Roles Anywhere collapses the gap between external workload authentication and AWS authorization, which means the certificate authority becomes part of the enterprise identity perimeter. If a single CA can issue credentials to many systems, the real problem is trust domain sprawl. Practitioners should treat the CA, the certificate, and the role mapping as one governed identity chain.

Certificate revocation only matters when it is operationally enforceable. A revocation list that is stale, inconsistently checked, or disconnected from downstream access decisions creates a false sense of control. The governance failure is stale credential persistence, where a revoked workload can continue to act as though it is still trusted. That is a lifecycle breakdown, not a policy nuance, and it belongs in the same risk register as any other standing NHI privilege.

Hidden NHI access becomes especially dangerous when ownership is missing. Certificates that are not tied to a person, team, system, or decommission date become orphaned identities with no accountable operator. That breaks the assumption that access can be reviewed against a stable owner. The result is access that survives longer than the workload it was meant to represent, which is exactly how blast radius expands in cloud programmes.

Certificate-to-role mapping creates the real privilege surface. The certificate authenticates the caller, but the AWS role determines what the caller can do. If the mapping is loose, the organisation has not solved workload identity governance, it has only moved it deeper into the stack. The practitioner question is whether entitlements are being governed at the point where authentication becomes effective privilege.

From our research:

• 72% of identity professionals find machine identities more challenging to manage than human identities, according to The Critical Gaps in Machine Identity Management report.
• 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
• For a governance baseline, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs before expanding certificate-based external access further.

What this signals

Certificate-based external access should now be treated as an NHI lifecycle problem, not an IAM exception. When trust anchors, revocation, and role profiles drift apart, the programme loses sight of who can actually act in AWS. Teams that already struggle with machine identity inventory should expect Roles Anywhere to surface the same ownership and offboarding gaps in a new form.

Hidden certificate privilege is a blast-radius issue before it is a tooling issue. If a certificate can assume a role that reaches customer data, the security question is how fast that path can be discovered and revoked, not whether the access model is technically supported. That is why the 52 NHI Breaches Analysis remains relevant here: identity exposure often becomes visible only after the access path has already been abused.

The operational signal to watch is whether certificate attribution can be tied back to a named owner, a named workload, and a measurable expiry or revocation state. If that cannot be shown consistently, the organisation is not governing workload identity, it is merely authenticating it. That is the gap that will widen first as external workload access expands.

For practitioners

• Tighten certificate issuance boundaries Limit each trust anchor to the smallest realistic workload population and require explicit ownership metadata for every certificate chain.
• Verify revocation enforcement end to end Test that revoked certificates are rejected in the actual access path, not just marked inactive in a control console or policy record.
• Audit certificate-to-role mappings Review every Roles Anywhere profile for over-broad role assumption and remove mappings that grant access beyond the workload's documented purpose.
• Add lifecycle offboarding for external workloads Treat workload decommissioning as an identity event by revoking certificates, removing trust anchors where possible, and closing orphaned profiles.

Key takeaways

• AWS Roles Anywhere creates real workload identity value, but only if certificate trust is bounded to named owners and specific workloads.
• Stale revocation, loose role mapping, and missing attribution turn certificates into persistent non-human privilege paths.
• The control objective is end-to-end lifecycle governance from certificate issuance to revocation to offboarding, not authentication alone.

Key terms

• Trust anchor: A trust anchor is the root authority that signs federation metadata and establishes the policies other participants inherit. In practice, it controls who can join, what cryptographic rules apply, and how trust is delegated across an ecosystem. The security posture of the whole federation depends heavily on this layer.
• Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.
• Certificate-to-Role Mapping: Certificate-to-role mapping is the policy step that turns a valid certificate into effective AWS privilege by allowing role assumption. It is the control point where authentication becomes authorisation, so loose mappings can convert a low-risk certificate into broad data access.
• Orphaned Access: Orphaned access is credentialed access that still works even though no clear business owner can justify or manage it. It usually appears after system changes, reorganisations, or integrations, and it is especially dangerous because it can remain active long after the original purpose has disappeared.

What's in the full article

Veza's full analysis covers the operational detail this post intentionally leaves for the source:

• Exact discovery logic for AWS IAM Roles Anywhere trust anchors, CRLs, and profiles across cloud estates
• The end-to-end certificate-to-role-to-permission mapping workflow used to expose hidden access paths
• Practical query examples for finding orphaned or over-permissive profiles before they become persistent exposure
• The breadth of AWS service coverage, including S3, EC2, and KMS, that implementation teams will want to validate

👉 Veza's full post covers trust anchors, CRLs, role mappings, and hidden access paths in more implementation detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.