Compliance Frameworks
BETA// Beta Mapping Disclaimer
Framework mappings are currently in beta. These references are generated based on technical specifications and common industry alignments. Mappings may be incomplete or inaccurate; always consult with a qualified auditor for official compliance validation.
Overview
Establish a documented, auditable break-glass access procedure for emergency access to the Management account when IAM Identity Center or the corporate IdP is unavailable.
Break-glass access is the emergency fallback when normal federated access via IAM Identity Center fails - typically due to an IdP outage, Identity Center service disruption, or misconfiguration that locks out all federated users. The pattern consists of a single dedicated IAM user in the Management account with AdministratorAccess, hardware MFA enforced via an IAM policy condition, credentials stored in a physical safe or a highly restricted Secrets Manager secret in a separate security account, and an immediate CloudWatch alarm triggered on any sign-in or API call by this user. The user has no access keys and no console access without MFA - the MFA device is the physical control that governs who can use the account. Usage is a declared incident: the security team is paged, all actions are recorded in CloudTrail, and the session is terminated as soon as normal access is restored. An SCP prevents deletion of the break-glass user from any account other than the Management account. Member accounts do not have their own break-glass users - emergency access to member accounts is obtained by assuming a role from the Management account break-glass session.
IAM Identity Center is a dependency for all human access in a well-configured landing zone. A single point of failure in the IdP or Identity Center configuration can lock out the entire operations team from the Management account during an active incident - precisely when access is most critical. A carefully controlled break-glass user with hardware MFA provides an out-of-band access path that does not depend on any federated identity infrastructure while remaining auditable and difficult to misuse.
Remediation Strategy
Create a single break-glass IAM user in the Management account with AdministratorAccess and hardware MFA enforced. Store credentials in a physical safe. Configure CloudWatch alarm and SNS notification for any usage. Document activation and deactivation procedures. Test annually.
Create a dedicated IAM user named break-glass in the Management account with no access keys and no console password until needed.
Attach AdministratorAccess and the MFA enforcement policy.
Enroll a hardware MFA device (FIDO2 security key or TOTP hardware token - not virtual MFA).
Store the console password and MFA device in a physical safe with dual-control access (two authorized persons required).
Configure the CloudWatch alarm and SNS topic to page the security team immediately on any break-glass activity.
Document activation conditions, step-by-step access procedure, and mandatory deactivation steps in the incident response runbook.
Test the full procedure annually in a controlled exercise - verify the alarm fires and credentials work.
Enforcement Logic
Two detection checks apply. First, verify the break-glass IAM user exists, has MFA enabled, and has no active access keys - deviations from any of these indicate the account is misconfigured or was tampered with. Second, a CloudWatch metric filter on CloudTrail logs detects any console sign-in or API call by the break-glass user and triggers an SNS alarm immediately - any activity outside a declared incident window is a security event.
# Confirm user exists and has MFA enabled
aws iam get-user \
--user-name break-glass \
--query "User.{Name:UserName,Created:CreateDate}" \
--output table
aws iam list-mfa-devices \
--user-name break-glass \
--query "MFADevices[*].{Serial:SerialNumber,Enabled:EnableDate}" \
--output table
# Confirm no active access keys
aws iam list-access-keys \
--user-name break-glass \
--query "AccessKeyMetadata[?Status=='Active'].AccessKeyId" \
--output textThe break-glass user is the only permitted IAM user with console access in the Management account. It is the explicit exception to the IAM user prohibition in AWS-IAM-004. It must be the only entry in any audit finding for active IAM login profiles in this account.
During an active declared incident, break-glass usage is expected and alarm notifications should be acknowledged by the on-call security lead rather than escalated as an unauthorized access event. A declared incident must be opened in the incident management system before break-glass credentials are retrieved from the safe.
Hardware MFA is mandatory for break-glass users - virtual MFA (authenticator app) stored on a personal device is not acceptable because device loss or compromise removes the physical control. Use a FIDO2 hardware key (YubiKey, Titan) or a dedicated TOTP hardware token stored with the credentials. The break-glass user should have no console password set in its normal state - the password is created as part of the activation procedure and deleted immediately after the session ends. This limits the window of exposure to the duration of the declared incident. Member account emergency access is handled by assuming an emergency role from the Management account session, not by creating break-glass users in every account. The CloudTrail log group name required by the Terraform alarm block must match the log group created by your CloudTrail configuration - typically /aws/cloudtrail or a custom name set in your landing zone baseline.