AWS IAM Roles Anywhere Security Guide

IAM Roles Anywhere swaps long-term AWS access keys on servers outside AWS for an X.509 certificate, which means the security of those workloads now rests on your PKI, your private key storage and three pieces of AWS configuration most teams set once and never revisit. On-premises servers, containers in other clouds and build agents that once held an IAM user's access key can instead present a certificate and receive temporary credentials for an IAM role. That is a real improvement, but a trust anchor pointing at a broad corporate CA, a role trust policy with no certificate conditions, a private key in a world-readable file or a missing CRL turns it into a different kind of standing credential. This guide covers the trust model, who should administer it, how the credential helper and session settings behave, what CloudTrail and expiry notifications give you, a hardening baseline with a phased migration, and the misconfigurations to look for. It is for AWS platform engineers, PKI owners and identity teams responsible for hybrid workloads.

Key takeaways

The account is the default trust boundary. AWS documents that a certificate from any trust anchor in an account can assume any role that trusts the service, unless the role's trust policy adds conditions.
Every role needs certificate conditions. Pin aws:SourceArn to one trust anchor and match aws:PrincipalTag/x509Subject/CN or a SAN tag, so one certificate maps to one role.
Revocation is CRL import only. IAM Roles Anywhere does not call CRL distribution points or OCSP; if you have not imported a CRL with ImportCrl, revoking a certificate at the CA does nothing in AWS.
The private key is now the credential. AWS does not hold it; keep it in a TPM, HSM, smart card or OS key store where possible, and never in source control.
Sessions are bounded twice. Profile session policies and managed policies cap what the role can do, and durationSeconds (900 to 43,200, default 3,600) caps how long stolen session credentials last.

How identity and access work in AWS IAM Roles Anywhere

A workload signs a CreateSession request with its certificate's private key and sends the certificate chain. The service validates the chain against a trust anchor, checks the imported CRL, assumes the requested role on the workload's behalf (AWS describes CreateSession as an X.509 wrapper around AssumeRole) and returns temporary credentials. All Roles Anywhere resources are regional and must sit in the same account and region to be used together.

Component	What it is	Security decision it carries
Trust anchor	Reference to an AWS Private CA or an uploaded external CA certificate	Which issuing CA can mint AWS access; how narrow that CA's issuance is
Profile	List of up to 250 role ARNs, optional session policy and up to 50 managed policies, session duration, `acceptRoleSessionName`, enabled flag	Maximum permissions and lifetime of any session vended through it
IAM role	Role whose trust policy names principal `rolesanywhere.amazonaws.com` with `sts:AssumeRole`, `sts:TagSession`, `sts:SetSourceIdentity`	Which certificates, from which anchor, can assume it
End-entity certificate and key	X.509v3, `CA:false`, Digital Signature key usage, SHA-256 or stronger signature, non-empty subject	Identity of the workload and the secret an attacker must steal
CRL	Imported through the `ImportCrl` API or CLI (not the console)	Whether revocation works at all

Certificate attributes become session context

Subject, issuer and the first DNS, URI and Directory Name SAN values are mapped to session tags such as aws:PrincipalTag/x509Subject/CN, aws:PrincipalTag/x509Issuer/O and aws:PrincipalTag/x509SAN/URI. Source identity is set from the subject CN (prefixed CN=), or ID= plus the serial number when there is no CN, and the role session name defaults to the hex-encoded certificate serial number. That gives every session a traceable link back to one certificate in CloudTrail, and lets identity and resource policies make decisions on certificate fields. Values that do not match the STS tag pattern are silently dropped, so test conditions with real certificates. AWS suggests SPIFFE-style URIs as one way to build a hierarchical workload namespace; see the SPIFFE and SPIRE Guide.

When to use Roles Anywhere and when not to

Workload location	Preferred mechanism	Reason
EC2, ECS, EKS, Lambda	Native instance, task or pod roles	No certificate lifecycle to run
Other cloud or SaaS CI with an OIDC issuer (GitHub Actions, GKE, Azure)	OIDC federation through `AssumeRoleWithWebIdentity`	The platform already issues short-lived signed tokens; see the Workload Identity Federation Guide
On-premises servers, appliances, VMs and containers with an existing enterprise PKI or SPIFFE deployment	IAM Roles Anywhere	No OIDC issuer, but certificates can be issued and protected in hardware
Hosts with no way to protect a private key and no PKI owner	Fix that first	A plaintext key file with a two-year certificate is little better than an access key

Small organisations with a handful of on-premises servers can run one AWS Private CA (or a tightly scoped external issuing CA) and one trust anchor per account. Larger estates should keep a dedicated issuing CA per environment or business unit, a trust anchor per CA, and automated issuance and renewal, because certificate expiry becomes an availability risk at scale. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Admin roles and privileged access

Whoever can change a trust anchor can decide which CA mints AWS credentials in the account. Treat these permissions like IAM administrator rights.

Action	Risk if abused	Control
`rolesanywhere:CreateTrustAnchor`, `UpdateTrustAnchor`	Attacker registers their own CA and issues certificates for any role whose trust policy lacks an `aws:SourceArn` condition	Restrict to a break-glass or pipeline role; alert on every call
`rolesanywhere:CreateProfile`, `UpdateProfile`	Remove the session policy, extend duration to 12 hours, add roles	Change through infrastructure as code only; alert on changes to `sessionPolicy`, `managedPolicyArns`, `durationSeconds`
`rolesanywhere:ImportCrl` and CRL updates	Replace the CRL with an empty one, un-revoking compromised certificates	Only the PKI automation role; compare imported CRL with the CA's published CRL
`iam:UpdateAssumeRolePolicy` on Roles Anywhere roles	Strip certificate conditions from a role's trust policy	Permissions boundary or SCP on role trust changes; alert
CA administration (AWS Private CA or on-premises CA)	Issue a certificate with any subject the trust policy expects	Separate PKI administrators from AWS administrators; dual control on issuance templates

Remember no organisation-wide integration: AWS states there is no automatic integration with organisation-wide controls, so each account's anchors and profiles need their own governance. Use SCPs to deny Roles Anywhere administration outside designated roles; see the AWS Organizations and SCPs Guide.
Tag-based administration: Roles Anywhere supports aws:ResourceTag, aws:RequestTag and aws:TagKeys (partial ABAC), which lets you limit teams to profiles carrying their own tag.
AWS Private CA validity changes: only the validity period can be changed after creation, and the service honours the validity from the latest CreateTrustAnchor or UpdateTrustAnchor event, so validity updates need an explicit trust anchor update.

Integrations, API tokens and service accounts

Most workloads use the AWS-published credential helper, aws_signing_helper. Its three modes have very different exposure.

Mode	Where credentials live	Exposure	Use when
`credential-process`	In memory, returned to the SDK through `credential_process` in `~/.aws/config`	Lowest: only the calling process receives them	Default choice for services and scripts
`serve`	In memory, served on an IMDSv2-compatible endpoint on `127.0.0.1` (default port 9911)	AWS warns any process that can reach 127.0.0.1 can retrieve the credentials; set `--hop-limit 1`	Legacy tools that only read instance metadata
`update`	Plaintext in `~/.aws/credentials`, refreshed about five minutes before expiry	Anyone who can read the file can use them (ATT&CK T1552.001 Credentials In Files)	Avoid; only where nothing else works

Key storage: the helper accepts a plaintext key file, a PKCS#11 URI (HSMs, smart cards, YubiKey PIV), a TPM 2.0 key (TSS2 key file or persistent handle) or a certificate selector for the Windows certificate store or macOS Keychain. AWS notes that a TSS2 key file is loaded as a transient object and is often the safer TPM choice, and that an unprotected persistent TPM key can be used by anyone with machine access. A key file needs owner-only permissions (for example chmod 600), per AWS's data protection guidance.
Do not disable TLS checks: --no-verify-ssl exists for tightly controlled debugging only; AWS warns it allows man-in-the-middle attacks.
Session names: leave acceptRoleSessionName at its default of false unless you need custom names; with it false, the session name is the certificate serial, which keeps CloudTrail attribution honest.
Network path: AWS supports interface VPC endpoints (AWS PrivateLink) for Roles Anywhere and requires TLS 1.2 (TLS 1.3 recommended). FIPS endpoints are available where required.
Replacing IAM users: every on-premises access key replaced removes a long-term secret like the administrative key behind the Imperva Breach. See the AWS IAM Policies and Roles Guide for role and policy design.

Logging and detection

CloudTrail records all Roles Anywhere API calls with event source rolesanywhere.amazonaws.com, including CreateSession. Successful CreateSession events carry additionalEventData with missingSignedHeaders, postEmptyBody and algorithmMismatch; non-empty or true values indicate a non-conforming client worth investigating. Sessions then appear in downstream CloudTrail events as the assumed role with the certificate serial as session name and the CN as source identity. Each Subject resource records first and last authentication times, which is a cheap way to find unused certificates.

Trust anchors also emit certificate expiry notifications. By default the CA certificate expiry event goes to CloudWatch metrics, EventBridge and AWS Health, and the end-entity certificate expiry event goes to EventBridge and AWS Health, both 45 days before expiry; thresholds are configurable per anchor.

Signal	Source	Alert on	ATT&CK
Trust anchor created, updated, enabled	CloudTrail management events	Any change outside the PKI pipeline; new external CA source	T1649 Steal or Forge Authentication Certificates
Profile changed	CloudTrail `UpdateProfile` request parameters	Session policy removed, managed policies widened, `durationSeconds` raised	T1098.003 Additional Cloud Roles
CRL imported or updated	CloudTrail	Entry count drops, or import by an unexpected principal	T1649
`CreateSession` anomalies	CloudTrail	New source IP range for a serial, same serial from two networks, signing anomalies in `additionalEventData`, failures spiking	T1552.004 Private Keys, T1078.004 Cloud Accounts
Role trust policy change	CloudTrail IAM `UpdateAssumeRolePolicy`	Removal of `aws:SourceArn` or certificate tag conditions	T1098.003
Certificate expiry	EventBridge, AWS Health	Expiry inside threshold without a renewal ticket	Availability

Metrics:

Remaining IAM user access keys on workloads outside AWS (target: falling to zero).
Percentage of Roles Anywhere roles whose trust policy pins aws:SourceArn and at least one certificate attribute.
Percentage of private keys in TPM, HSM or OS key store rather than files.
Age of the imported CRL compared with the CA's publication schedule.
Median end-entity certificate validity, and certificates renewed before expiry notification versus after.
Subjects with no authentication in 90 days (candidates for revocation).

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Certificate-based service authentication	IA-9 Service Identification and Authentication, IA-5 Authenticator Management	PR.AA-01
PKI and key protection	SC-17 Public Key Infrastructure Certificates, SC-12 Cryptographic Key Establishment and Management	PR.AA-01
Role and session scoping	AC-6 Least Privilege	PR.AA-05
Inventory of certificates and subjects	CM-8 System Component Inventory, AC-2 Account Management	PR.AA-01
Logging and review	AU-12 Audit Record Generation, AU-6 Audit Record Review, Analysis, and Reporting	DE.CM-03

Hardening baseline

Dedicated issuing CA: trust an issuing CA used only for AWS workload certificates, never the enterprise root or a CA that issues user, VPN or web server certificates.
Role trust conditions: ArnEquals aws:SourceArn to the specific trust anchor, plus StringEquals on aws:PrincipalTag/x509Subject/CN, x509SAN/URI or x509SAN/DNS. AWS recommends combining aws:SourceArn or aws:SourceAccount with sts:SourceIdentity against confused deputy issues.
Profile limits: one profile per workload class, a session policy or managed policies that cap permissions below the role's, and durationSeconds at 3,600 or less unless justified.
Revocation: automate CRL import on the CA's publication schedule, and test that a revoked certificate fails CreateSession.
Short certificates: end-entity validity measured in days or weeks with automated renewal, not years.
Hardware-backed keys and the credential-process mode wherever the host allows.
Administration through code: anchors, profiles, CRLs and role trust policies in infrastructure as code, with SCPs denying console changes.

Phased migration from access keys

Inventory: list IAM users with active access keys used from outside AWS (credential reports and last-used data) and map each to a host, owner and required permissions.
Build the PKI side: stand up the dedicated issuing CA, define the subject or SPIFFE URI naming scheme, choose key storage per host type and automate issuance, renewal and CRL publication.
Configure AWS in a test account: create the trust anchor, set notification thresholds, import the CRL, create conditioned roles and a profile with a session policy. Verify a wrong-CN certificate and a revoked certificate are both denied.
Pilot: move one low-risk workload to credential-process, run it in parallel with the old key for a business cycle and compare CloudTrail actions. Rollback is re-enabling the old key, so deactivate it rather than delete it at first.
Cut over in waves: deactivate each access key after its workload has run cleanly on Roles Anywhere, delete after a grace period, and remove the IAM user.
Enforce: alert on new IAM user access keys, block them with SCPs where possible, and run quarterly reviews of anchors, profiles, trust policies and unused subjects.

Common misconfigurations

Trust policy with only the service principal: no aws:SourceArn and no certificate tag condition, so any certificate from any anchor in the account can assume the role, including a test anchor someone added later.
Enterprise root as trust anchor: every certificate the organisation has ever issued, including user and device certificates, becomes a candidate AWS credential limited only by role conditions.
No CRL imported: teams revoke at the CA and assume AWS checks it. It does not fetch CDP or OCSP, so the stolen certificate keeps working until expiry.
Keys in files next to long-lived certificates: a key readable by any local user, with a two-year certificate, copied into a container image or backup. Theft (T1552.004 Private Keys) gives an attacker the same standing access an access key did.
Profiles without session policies and with 12 hour sessions: the profile adds nothing, and every vended credential lives as long as possible.
Ignoring expiry notifications: the default 45 day events go to EventBridge and AWS Health but nobody subscribes, and the first signal is a production outage when the CA or end-entity certificate expires. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Practitioner checklist

Use a dedicated issuing CA per environment as the trust anchor, never an enterprise root.
Pin every Roles Anywhere role trust policy to one aws:SourceArn and at least one certificate attribute.
Attach a session policy or managed policies to every profile and keep durationSeconds at 3,600 or below unless justified.
Automate CRL import and prove revocation works with a test certificate.
Store private keys in TPM, HSM, smart card or OS key store; otherwise owner-only file permissions and short certificate validity.
Use credential-process mode; avoid update, and set --hop-limit 1 if serve is unavoidable.
Restrict trust anchor, profile, CRL and role trust policy changes to pipeline roles and alert on every change.
Subscribe to CA and end-entity expiry events and route them to the certificate owner.
Track and retire IAM user access keys used outside AWS until none remain.

AWS IAM Roles Anywhere Security Guide: Trust Anchors, Profiles and Certificate Hygiene