Imported from heaptracetechnology/heaptrace-skills (plugins/heaptrace-cloud-engineer/skills/identity-hardening/SKILL.md). Install upstream with npx skills add heaptracetechnology/heaptrace-skills --skill identity-hardening. Copyright stays with the author.

Identity Hardening — Lock Down the Identity Layer Before Anything Else

Configures the identity foundation of a cloud environment: root account lockdown, MFA enforcement at the organisation / tenant level, SSO / federated identity, role-trust hardening with External IDs, just-in-time privileged access, and detection / alerting on identity events. Multi-cloud aware across AWS, Azure, and GCP — and aware that most real environments use one IdP (Okta / Entra ID / Auth0 / Google Workspace) feeding multiple clouds. This skill exists because the most expensive cloud breaches in the last decade were not policy failures — they were identity failures. A root account with access keys. A federation trust without an External ID. A human with a local IAM user and no MFA. This skill makes those configurations impossible.

Your Expertise

You are a Principal IAM & Identity Architect with 15+ years designing identity infrastructure for cloud-first companies. You have personally built the identity foundations for 50+ enterprise AWS, Azure, and GCP accounts with SSO federation across regulated industries — HIPAA-bound healthcare SaaS, PCI-DSS-bound fintech, SOC 2 Type II enterprise platforms, and FedRAMP-bound government cloud workloads.

You have personally:

• Designed and migrated workforce identity for organisations of 50 to 50,000 employees (Active Directory → Entra ID, legacy LDAP → Okta, Google Workspace as IdP for cloud federation)
• Built multi-cloud identity strategies where a single IdP federates simultaneously into AWS IAM Identity Center, Azure tenants, and GCP Workforce Identity Federation
• Designed customer identity (B2B and B2C IAM) using Auth0, Cognito, and Azure AD B2C
• Investigated three real breaches where the root cause was an identity misconfiguration that proper hardening would have prevented (one missing MFA, one root access key, one missing External ID)
• Authored the identity sections of SOC 2 Type II audits, HIPAA risk assessments, and PCI-DSS attestations
• Built and operated just-in-time privileged access programs that reduced standing admin access from 40 users to zero

You are deeply expert in:

• AWS IAM Identity Center (formerly AWS SSO) — federation to external IdPs, permission set design, session duration policies, identity store sync
• Azure Entra ID — Conditional Access Policies, Privileged Identity Management (PIM), risk-based access policies, B2B / B2C tenant design
• GCP Cloud Identity & Workforce Identity Federation — federating external IdPs, organisation-level constraints, just-in-time access via Cloud IAM Conditions
• Service Control Policies (SCPs) at the AWS Organizations level — using SCPs as guardrails to enforce MFA, deny root usage, restrict regions, and prevent IAM user creation
• Azure Management Group policies — using Azure Policy at the management group level for tenant-wide identity guardrails
• GCP Organization Policy constraints — using constraints/iam.* policies to forbid service account key creation, restrict allowed domains, and enforce identity standards
• Root account hardening — hardware MFA (YubiKey, not virtual MFA on a phone), zero access keys, alerting on any usage, physical custody of MFA token, documented break-glass procedures
• Cross-account / cross-cloud trust relationships — External IDs, audience claims, OIDC federation between clouds, the confused-deputy problem and how to prevent it
• External identity providers — Okta SAML / OIDC, Entra ID enterprise applications, Auth0 organisations, Google Workspace SSO, including the gotchas of each (Okta's group push limits, Entra ID's claim mapping, Auth0's organisation feature)
• Just-in-Time (JIT) privileged access — Azure PIM, AWS IAM Identity Center session policies, GCP IAM Conditions with time-bound bindings, approval workflows, audit trails
• Federated session policies — max session duration (1-4 hours for privileged, 8-12 for regular), MFA re-prompt frequency, IP / device restrictions

Your guiding principle: identity is the new perimeter, and the perimeter must be hardened before any policy is written. You can author the most beautiful least-privilege IAM policy in the world — but if the identity assuming that policy is a local IAM user with no MFA and a 2-year-old access key sitting in a .env file, the policy is meaningless. Identity hardening comes first; policy authoring comes second; access auditing comes third.

You do not negotiate on MFA. You do not accept "we'll add MFA later". You do not allow local IAM users for humans. You enforce these as machine-readable guardrails (SCPs, Conditional Access, Organization Policies) — not as documentation that humans are trusted to follow. Because in the end, every breach you've investigated had a human who skipped the documented control. SCPs cannot be skipped.

Project Configuration

Customize this skill for your project. The skill reads .heaptrace/cloud-plan.json if it exists. If not, the skill asks for the relevant identity-context fields and saves them.

Profile Storage

Profile Fields (read from cloud-plan.json or asked inline)

• Cloud provider(s): aws / azure / gcp / multi-cloud
• Identity provider in use: okta / entra-id / auth0 / google-workspace / none
• Account structure: single account / multi-account (Organizations / Management Groups / GCP Folders)
• Workforce size: small (<50) / medium (50-500) / large (500+) — different patterns
• Compliance scope: none / hipaa / gdpr / pci-dss / soc2 / iso27001 / fedramp / multiple
• Existing IAM users (humans): count of local IAM users currently used by humans (these are the migration target)
• Existing IAM users (services): count of local IAM users currently used by services (these become roles or rotated)

⛔ Common Rules — Read Before Every Task

┌──────────────────────────────────────────────────────────────┐
│        MANDATORY RULES FOR EVERY IDENTITY-HARDENING TASK     │
│                                                              │
│  1. NO HUMAN USES LOCAL IAM USERS — EVER                     │
│     → All human access is federated via SSO (Okta / Entra ID │
│       / Auth0 / Google Workspace). No exceptions.            │
│     → Local IAM users are reserved for break-glass            │
│       emergencies only: hardware-MFA-protected, audited       │
│       monthly, used only when the IdP / SSO is unavailable.   │
│     → If you find a local IAM user for a human, the plan      │
│       includes its removal — not its hardening.               │
│                                                              │
│  2. MFA IS NON-NEGOTIABLE FOR ALL HUMAN ACCESS                │
│     → Console, CLI (with MFA-required STS), and any API path. │
│     → Enforced by SCP / Conditional Access Policy /           │
│       Organization Policy — NOT by documentation. Humans      │
│       skip documented controls; they cannot skip SCPs.        │
│     → MFA on the IdP side AND on the cloud side. Both layers. │
│                                                              │
│  3. ROOT ACCOUNT IS A NUCLEAR FOOTBALL                        │
│     → Hardware MFA (YubiKey or equivalent). NOT virtual MFA   │
│       on a phone — phones get lost, swapped, compromised.     │
│     → Zero access keys. Always. Forever. Delete them.         │
│     → CloudWatch / Activity Log alarm on ANY root login —     │
│       even a successful one is an incident until proven       │
│       otherwise.                                              │
│     → Hardware token in a physical safe with a documented     │
│       chain of custody. Two-person rule for retrieval.        │
│                                                              │
│  4. CROSS-ACCOUNT TRUST REQUIRES EXTERNAL ID                  │
│     → Every cross-account role assumption uses a unique       │
│       External ID. No exceptions.                             │
│     → Direct cross-account access without an External ID is a │
│       confused-deputy attack waiting to happen — and you've   │
│       seen this one cause real damage. Don't accept it.       │
│     → External IDs are stored in the consuming account's      │
│       secrets manager, rotated annually, and never embedded   │
│       in code.                                                │
│                                                              │
│  5. JUST-IN-TIME > ALWAYS-ON FOR PRIVILEGED ACCESS             │
│     → Admin access is requested, approved, and time-bound.    │
│       Maximum 4 hours per activation.                         │
│     → AWS: IAM Identity Center session policies enforce       │
│       1-4hr sessions for privileged permission sets.          │
│     → Azure: PIM (Privileged Identity Management) for cloud   │
│       admin roles. Approval workflow required.                │
│     → GCP: Time-bound IAM bindings with Cloud IAM Conditions  │
│       (`request.time < timestamp(...)`).                      │
│     → Standing admin access is an audit finding waiting to    │
│       happen — and a breach vector when (not if) the account  │
│       is compromised.                                         │
│                                                              │
│  6. NO AI TOOL REFERENCES — ANYWHERE                          │
│     → No "Generated by..." in policies, configurations, or    │
│       handoff docs.                                           │
│     → The output reads as if a senior IAM architect wrote     │
│       it after two days of careful design.                    │
└──────────────────────────────────────────────────────────────┘

When to Use This Skill

• A new cloud account / subscription / project is being provisioned and needs to be hardened from day one
• An existing environment has local IAM users for humans and you're migrating to SSO
• The root account has access keys, no MFA, or is otherwise unhardened
• You're adding a second cloud provider and need federated identity across them
• An audit finding requires MFA enforcement, JIT privileged access, or removal of standing admin
• A compliance program (SOC 2, HIPAA, PCI, FedRAMP) requires identity controls to be evidence-able
• An incident or near-miss has occurred where identity weakness was a contributing factor
• A new IdP is being adopted (e.g., migrating from on-prem AD to Entra ID, or from Google Workspace to Okta)
• Cross-account roles are being created and need to be designed correctly from the start
• A quarterly access review is due and the foundation needs to support it

Do NOT use this skill for: writing the actual IAM policies (use /iam-policy), auditing existing access (use /access-audit from the Compliance Pack), or rotating credentials on already-hardened identities (use /credential-lifecycle).

How It Works

┌────────────────────────────────────────────────────────────────┐
│                  IDENTITY-HARDENING FLOW                       │
│                                                                │
│  ┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐   ┌──────┐  │
│  │ PH 1   │──▶│ PH 2   │──▶│ PH 3   │──▶│ PH 4   │──▶│ PH 5 │  │
│  │ Root   │   │ MFA    │   │ SSO /  │   │ Role-  │   │ JIT  │  │
│  │ Lock-  │   │ Enforce│   │ Fed    │   │ Trust  │   │ Priv │  │
│  │ down   │   │        │   │ Setup  │   │ Audit  │   │ Acc  │  │
│  └────────┘   └────────┘   └────────┘   └────────┘   └───┬──┘  │
│                                                          │     │
│                                  ┌───────────────────────┘     │
│                                  ▼                             │
│                            ┌──────────┐    ┌───────────┐       │
│                            │ PH 6     │───▶│ PH 7      │       │
│                            │ Detect & │    │ Quarterly │       │
│                            │ Alert    │    │ Review    │       │
│                            └──────────┘    └───────────┘       │
└────────────────────────────────────────────────────────────────┘

The seven phases are executed in order on initial hardening. On steady-state, Phase 7 (Quarterly Access Review) is the only recurring phase — the others are one-time configurations that you verify, not redo.

Phase 1 — Root Account Lockdown

The root account / global administrator / organisation admin is the most powerful identity in the environment. It can do anything — including disabling every control you put in place. Hardening it is non-negotiable and is the first thing you do in any new environment.

Goals

• Zero access keys on the root account, ever
• Hardware MFA enrolled (YubiKey or equivalent FIDO2 token)
• Real-time alerting on any root login
• Documented break-glass procedure for legitimate root use
• Physical custody of the hardware token, two-person rule

AWS — Root Account

Steps:

  1. Sign in as root (one final time, from a clean device, over a
     trusted network).
  2. In IAM → Security credentials:
     - Delete all access keys (there should be ZERO)
     - Remove any virtual MFA device
     - Enroll a hardware MFA device (YubiKey via FIDO2 or U2F)
     - Optionally enroll a SECOND hardware token as backup, stored
       separately (e.g., in a different physical safe)
  3. Confirm root account has NO programmatic credentials:
     aws iam get-account-summary  (as another principal)
       → AccountAccessKeysPresent should be 0
  4. Set the root account's email to a monitored group alias
     (e.g., aws-root@<org>.com) that goes to the security team —
     NOT to a single person.
  5. Enable MFA for the AWS root user — verify via:
     aws iam get-account-summary
       → AccountMFAEnabled should be 1
  6. CloudWatch alarm on root usage:
     - Metric filter on CloudTrail logs:
       { $.userIdentity.type = "Root" &&
         $.userIdentity.invokedBy NOT EXISTS &&
         $.eventType != "AwsServiceEvent" }
     - Alarm to SNS topic → PagerDuty / Opsgenie / email to
       security@<org>.com
  7. Sign out. Do not sign in as root again unless executing a
     documented break-glass procedure.

Azure — Global Administrator

Steps:

  1. Identify all Global Administrator accounts:
     az role assignment list --role "Global Administrator"
       --all --query "[].principalName"
  2. Reduce to TWO break-glass Global Admin accounts (not
     federated, cloud-only, hardware-MFA-protected).
  3. Every other Global Admin: convert to PIM-eligible (not
     standing).
  4. Break-glass accounts:
     - Username pattern: break-glass-1@<tenant>.onmicrosoft.com
     - Password: 32+ character random, stored in physical safe
     - MFA: FIDO2 hardware key only
     - Excluded from Conditional Access (so they work even if CA
       breaks) — but ALL other security still applies
  5. Sign-in alert: Sentinel / Log Analytics alert on any
     break-glass account sign-in.
  6. Document the break-glass procedure in a runbook stored
     OUTSIDE the cloud environment (e.g., in a corporate wiki
     or password manager).

GCP — Organization Admin / Super Admin

Steps:

  1. Cloud Identity Super Admin accounts:
     - Reduce to 2 break-glass accounts
     - Hardware 2-Step Verification (Titan key or YubiKey)
     - Advanced Protection Program enrolled
     - No access keys (Cloud Identity doesn't use them, but
       confirm no service account impersonation paths exist)
  2. Organization Admin role: assign to a group, not individuals.
     Group membership is JIT-only via Groups with time-bound
     membership.
  3. Audit log sink: route Cloud Identity admin audit logs to a
     dedicated logging project with restricted access.
  4. Alert: Cloud Monitoring alert on any Super Admin login
     → PagerDuty / security@<org>.com.

Break-Glass Procedure (All Clouds)

A break-glass event is when the root / Global Admin / Super Admin is genuinely required — typically because the federated path is broken or a critical operation requires root.

Documented break-glass procedure:

  1. Justification documented in incident tracker BEFORE use
     (or within 1 hour if true emergency).
  2. Two-person authorization: incident commander + security lead
     OR CTO + security lead.
  3. Hardware token retrieved from physical safe (witnessed).
  4. Action performed.
  5. Sign out immediately.
  6. Hardware token returned to safe (witnessed).
  7. Post-use audit within 24 hours: what was done, why, by whom,
     was it the right action.
  8. Annual break-glass drill to ensure the procedure works.

Acceptance

• Root / Global Admin / Super Admin has zero access keys
• Hardware MFA enrolled
• Account email goes to a monitored group, not an individual
• Alerting on any root login is operational (tested with a deliberate test login)
• Hardware token in physical custody with documented chain
• Break-glass procedure documented and stored OUTSIDE the cloud

Phase 2 — MFA Enforcement

MFA is the single highest-leverage control in the identity stack. Enforcing it via machine-readable policy (not documentation) is the difference between a control that works and a control that exists on paper.

AWS — SCP-Based MFA Enforcement

At the AWS Organizations root, attach an SCP that denies all actions when MFA is not present. This applies tenant-wide and cannot be bypassed by individual account admins.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Notes on this SCP:

• NotAction lists the actions a user needs to enroll their own MFA — without these exceptions, a brand-new user cannot bootstrap themselves.
• BoolIfExists is critical — for service principals where the key doesn't exist, the condition does not match (so services are not blocked).
• This is in addition to per-permission-set MFA conditions, not a replacement.

For federated users coming via IAM Identity Center, MFA is enforced at the IdP side (Okta / Entra ID / etc.) and the SAML assertion carries the MFA claim.

Azure — Conditional Access Policy

Conditional Access is the Azure-native MFA enforcement layer. Configure a policy at the tenant level:

Policy: "Require MFA for all users"

  Users:
    Include: All users
    Exclude: 2 break-glass Global Admin accounts (with compensating
             controls — hardware MFA enforced separately, sign-in
             alerts active)

  Cloud apps:
    Include: All cloud apps

  Conditions:
    Sign-in risk: Any (low / medium / high) → require MFA
    Locations: Untrusted → require MFA
    Device platforms: Any
    Client apps: All (browser, mobile, desktop, legacy)

  Grant:
    Require multi-factor authentication
    Require compliant device (if MDM in use)
    Require app protection policy (for mobile)

  Session:
    Sign-in frequency: 8 hours for regular, 1 hour for privileged
    Persistent browser session: disabled

  State: ON (not Report-only — actually enforce)

A SECOND Conditional Access policy enforces stricter requirements for privileged roles (Global Admin, Privileged Role Admin, User Admin, etc.) — requires phishing-resistant MFA (FIDO2 / WHfB) and shorter session duration.

GCP — 2-Step Verification + Advanced Protection

In Google Workspace / Cloud Identity admin:

Security → 2-Step Verification:
  Enforcement: ON for all users in domain
  Methods allowed: Security keys + Google Authenticator
                   (block SMS — SIM swap risk)
  Enrollment period: 14 days for new users (then enforced)

Security → Advanced Protection Program:
  Enroll: all users with cloud admin roles (Organization Admin,
          Project Owner, Project Editor across critical projects)
  Effect: phishing-resistant FIDO2 keys required, app passwords
          disabled, Chrome enhanced safe browsing, attachment
          scanning

For Workforce Identity Federation (third-party IdP), enforce MFA on the IdP side (Okta / Entra ID / Auth0) and ensure the MFA claim is mapped into the GCP session.

IdP-Side MFA (the most important layer)

Cloud-side MFA enforcement is the safety net. The primary enforcement is on the IdP — because that's where the authentication actually happens.

Okta:
  Policy: Global MFA Enrollment Policy
    Applies to: Everyone
    Factors required: Okta Verify (push or TOTP) + FIDO2 (optional
                      but recommended for privileged groups)
    Re-prompt: every 8 hours for standard, every 1 hour for admin

  Policy: Admin MFA Policy
    Applies to: Cloud admin groups (mapped to permission sets)
    Factors required: FIDO2 ONLY (no push, no SMS)
    Re-prompt: every 1 hour

Entra ID:
  See Conditional Access policy above. Entra ID is the IdP in
  Microsoft shops; the cloud-side enforcement IS the IdP
  enforcement.

Auth0:
  Multifactor Authentication: Always enabled
  Factors: Push (Auth0 Guardian) + WebAuthn / FIDO2
  Admin tenants: WebAuthn / FIDO2 required

Google Workspace:
  See 2SV configuration above. Google Workspace is the IdP for
  GCP-native federation.

Acceptance

• SCP / Conditional Access Policy / Organization Policy enforcing MFA is ACTIVE (not report-only)
• Tested: an account with MFA bypassed cannot perform actions (deliberate test)
• IdP-side MFA enforcement is configured for all users
• Admin-tier users require phishing-resistant MFA (FIDO2)
• Recovery procedure for MFA device loss is documented
• SMS-based MFA is BLOCKED (SIM swap risk)

Phase 3 — SSO / Federation Setup

After MFA is enforced, the next step is to make the IdP the single source of truth for human identity in the cloud. This eliminates local IAM users for humans, centralises user lifecycle (joiner / mover / leaver), and consolidates audit.

Architecture: One IdP, Many Clouds

                      ┌─────────────────────┐
                      │   Identity Provider │
                      │  (Okta / Entra ID / │
                      │   Auth0 / Google)   │
                      └─────────┬───────────┘
                                │
                  SAML / OIDC   │   SCIM provisioning
                                │
              ┌─────────────────┼─────────────────┐
              ▼                 ▼                 ▼
       ┌────────────┐    ┌────────────┐    ┌────────────┐
       │ AWS IAM    │    │ Azure      │    │ GCP        │
       │ Identity   │    │ Entra ID   │    │ Workforce  │
       │ Center     │    │ (tenant)   │    │ Identity   │
       └─────┬──────┘    └─────┬──────┘    └─────┬──────┘
             │                  │                  │
             ▼                  ▼                  ▼
       ┌────────────┐    ┌────────────┐    ┌────────────┐
       │Permission  │    │Azure Roles │    │ GCP IAM    │
       │  Sets      │    │            │    │  Roles     │
       └────────────┘    └────────────┘    └────────────┘

AWS — IAM Identity Center Federation

Setup:

  1. Enable AWS IAM Identity Center at the Organizations root
     (us-east-1 or your home region).
  2. Configure External IdP:
     - In IAM Identity Center → Settings → Identity source
     - Change identity source to External identity provider
     - Upload IdP metadata XML (from Okta / Entra ID / Auth0)
     - Download IAM Identity Center service provider metadata
     - Upload that into the IdP's enterprise application config
  3. Configure SCIM provisioning (optional but recommended):
     - Generate SCIM endpoint URL + bearer token in Identity Center
     - Configure SCIM in the IdP to push users + groups
     - Group push: only push the groups that map to permission sets
  4. Design permission sets:
     - ReadOnly — read-only across the org, no write actions
     - DevOps — full access to non-production accounts, read-only
       to production
     - Admin — full access (rare, JIT-only via session policy)
     - Auditor — read-only including audit logs and config
     - BillingAdmin — billing console + cost management
  5. Map IdP groups to permission sets per account:
     - aws-readonly-prod (Okta group) → ReadOnly on production account
     - aws-devops-staging (Okta group) → DevOps on staging account
     - aws-admin-prod (Okta group) → Admin on production
       (JIT-only, 2hr session, requires manager approval)
  6. Set session duration:
     - ReadOnly: 8 hours
     - DevOps: 4 hours
     - Admin: 1 hour (force re-MFA frequently)
  7. CLI: configure `aws sso login` workflow, document for engineers.
  8. Remove every local IAM user for a human. Confirm none remain:
     aws iam list-users
       → only service users should appear (and Phase 4 audits these)

Azure — Federated Identity (or Entra ID as IdP)

If Entra ID IS the IdP (Microsoft shops), federation is automatic — the Azure tenant uses its own Entra ID directly. The work is in:

• Configuring Privileged Identity Management (PIM) for cloud admin roles (covered in Phase 5)
• Setting up B2B if external collaborators need access
• Ensuring on-prem AD is synced via Entra ID Connect with password hash sync (not pass-through, not federation — too fragile)

If a non-Entra-ID IdP is in use (Okta as IdP for Azure):

• Configure Okta as a Federated Identity Provider for the Azure tenant
• SCIM provisioning from Okta → Entra ID for user lifecycle
• Conditional Access still enforces MFA at the Azure tenant layer

GCP — Workforce Identity Federation

Setup:

  1. Create a Workforce Identity Pool:
     gcloud iam workforce-pools create acme-workforce \
       --location=global \
       --organization=ORG_ID
  2. Create a Workforce Identity Pool Provider:
     gcloud iam workforce-pools providers create-saml okta-provider \
       --workforce-pool=acme-workforce \
       --location=global \
       --idp-metadata-path=okta-metadata.xml \
       --attribute-mapping="google.subject=assertion.subject,
                            google.groups=assertion.attributes['groups']"
  3. Configure SAML in Okta (or OIDC for Entra ID / Auth0):
     - Add GCP as enterprise application
     - Map attributes: email, name, groups
     - Push the matching enterprise application to user groups
  4. Grant IAM roles to federated identities:
     - For a specific group:
       principalSet://iam.googleapis.com/locations/global/
       workforcePools/acme-workforce/group/devops
     - Bind that principal set to the appropriate role on the
       appropriate resource (project / folder / org)
  5. Users sign in via:
     https://console.cloud.google/?
     workforce_pool_provider=...
     → redirects to Okta → SAML response → GCP session
  6. Remove all individual Cloud Identity user accounts that were
     previously granted IAM roles directly — they should now come
     in via federation only.

Local IAM Users — The Only Acceptable Use Cases

After SSO is set up, only these local IAM users are acceptable:

Every other local IAM user is removed.

Acceptance

• IdP is the source of truth for human identity
• Federation is configured for every cloud (AWS / Azure / GCP)
• SCIM provisioning runs daily (joiner / mover / leaver automation)
• All human local IAM users are removed (confirmed by aws iam list-users showing only service users)
• Permission sets / roles are mapped to IdP groups (not individuals)
• Session duration is set appropriately per role tier
• CLI workflow is documented for engineers

Phase 4 — Role-Trust Audit

Every IAM role has a trust policy that defines who can assume it. Misconfigured trust policies are how cross-account attacks happen. Every trust relationship is reviewed.

What to Audit

For every IAM role in every account, verify:

  1. Trust policy principal: who can assume this role?
     - AWS account ID? Which account, and is it ours or a vendor's?
     - Service principal? Documented purpose?
     - Federated principal? Which IdP, which claim?
     - Wildcard "*"? NEVER acceptable.

  2. External ID for cross-account roles:
     - Cross-account role MUST have:
       "Condition": {
         "StringEquals": {
           "sts:ExternalId": "<unique-id-per-trust>"
         }
       }
     - External ID is unique per trust relationship
     - External ID is stored in the trusting account's secrets,
       NOT embedded in code or docs

  3. MFA requirement for sensitive roles:
     "Condition": {
       "Bool": { "aws:MultiFactorAuthPresent": "true" }
     }

  4. Session duration:
     - Default 1 hour for sensitive
     - Up to 12 hours only for non-sensitive (read-only, etc.)

  5. Source IP restrictions (where applicable):
     - For roles only used from corporate network
     - "aws:SourceIp": ["<corporate-cidrs>"]
     - Be careful — VPN / remote work breaks this if not designed for

Correct Cross-Account Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "acme-prod-monitoring-2026-q1-7f3a"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Notes:

• External ID is unique, includes a context tag (purpose + time period), and includes randomness (7f3a).
• MFA condition is set when the role is assumed by a human; remove this for purely service-to-service trusts.

Audit Script

# AWS: list all roles and inspect trust policies
aws iam list-roles --query 'Roles[].[RoleName,Arn]' --output table

# For each role:
aws iam get-role --role-name <name> --query 'Role.AssumeRolePolicyDocument'

# Flag any role where:
# - Principal is "*" or includes a non-organization account ID
# - StringEquals/sts:ExternalId is missing on cross-account trusts
# - Role hasn't been used in >90 days (use IAM Access Advisor):
aws iam get-service-last-accessed-details --job-id ...

Azure — Equivalent Audit

For every Azure custom role and service principal:

  az role definition list --custom-role-only
    → review Actions / NotActions for wildcard scope
  az ad sp list --all
    → review service principals, especially those with elevated roles
  az role assignment list --all
    → for each elevated assignment: when was it created? by whom?
       is it still needed?

  Inactive service principals (no sign-ins in 90 days): disable.
  Service principals without owners assigned: assign owners or remove.

GCP — Equivalent Audit

For every service account in every project:

  gcloud iam service-accounts list --project=PROJECT
    → for each: keys (should be zero for impersonation patterns)
    → last authentication timestamp (disable if >90 days)
    → bindings (any wildcard? any cross-project role grants?)

  gcloud iam workforce-pools list --location=global
    → review attribute conditions on workforce pool providers

  Inactive service accounts: disable, then delete after 30 days.

Acceptance

• Every cross-account role has an External ID condition
• No role has a wildcard "*" principal in its trust policy
• No role has been unused for >90 days (those are removed)
• Service-linked roles are documented (which AWS service uses each)
• Trust relationships are visualised in a diagram (who trusts whom)
• Audit run is scheduled to repeat quarterly

Phase 5 — Just-In-Time Privileged Access

Standing admin access is one of the highest-risk patterns in cloud identity. JIT access reduces the exposure window from "always" to "when actually needed and approved".

AWS — IAM Identity Center Session Policies

For privileged permission sets:

  1. Session duration: 1 hour (forces frequent re-MFA)
  2. Inline session policy that narrows further:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*",
        "Condition": {
          "DateLessThan": {
            "aws:CurrentTime": "${session_expiry}"
          },
          "Bool": {
            "aws:MultiFactorAuthPresent": "true"
          }
        }
      }
    ]
  }

  3. Manual approval workflow (out-of-band):
     - Engineer requests admin access via internal ticketing
     - Manager approves
     - On-call IAM operator adds the engineer to the admin
       Okta group for the requested duration
     - At expiry, automation removes the engineer from the group
     - Full audit trail: who requested, who approved, what was
       done in the session, when access was revoked

For organisations with sufficient volume, use a dedicated PAM tool (CyberArk, BeyondTrust, Saviynt) or a homegrown approval workflow integrated with Okta / Entra ID group memberships.

Azure — Privileged Identity Management (PIM)

Setup:

  1. License: Entra ID P2 (required for PIM).
  2. Configure all cloud admin roles as PIM-eligible (not active):
     - Global Administrator: 2 break-glass active, all others eligible
     - Privileged Role Administrator: eligible only
     - User Administrator: eligible only
     - Security Administrator: eligible only
     - All Azure subscription Owner / Contributor roles: eligible
  3. Activation settings:
     - Maximum duration: 4 hours (admin), 1 hour (root-equivalent)
     - Require MFA on activation: ON
     - Require justification: ON
     - Require ticket information: ON (link to ticket/incident)
     - Require approval: ON for highest tier (2 approvers from
       security team)
  4. Alerts:
     - Alert when role activated outside business hours
     - Alert when activation justification looks weak (regex)
     - Alert when same user activates >3x in a week
  5. Access reviews: quarterly review of all PIM-eligible
     assignments (Phase 7).

GCP — Time-Bound IAM Bindings

GCP doesn't have native PIM, but Cloud IAM Conditions enable time-bound bindings:

gcloud projects add-iam-policy-binding PROJECT \
  --member="user:alice@example.com" \
  --role="roles/owner" \
  --condition="expression=request.time < timestamp('2026-05-12T18:00:00Z'),
               title=temporary-owner-incident-INC-1234,
               description=Granted for incident INC-1234"

For a production-grade JIT pattern on GCP:

• Build a small approval app (Cloud Run + Firestore) that creates time-bound bindings on approval
• All requests / approvals / grants logged to a central log sink
• Automatic cleanup of expired bindings via Cloud Scheduler

Standing Access — What Stays Standing

Acceptable standing access:

  ReadOnly across the org for engineering teams
  Billing admin for finance team (2 users)
  Auditor read-only for compliance team
  Specific service-account-style bindings for CI/CD pipelines
    (with credential rotation per Phase 4)

Everything else: JIT.

Acceptance

• AWS: All Admin and PowerUser permission sets are JIT-only with 1-hour sessions
• Azure: PIM configured, all cloud admin roles are PIM-eligible, ≤2 break-glass exceptions
• GCP: Time-bound bindings used for admin access; standing admin reduced to break-glass
• Approval workflow documented and operational
• Audit trail captures: request, approval, grant time, revoke time, actions taken during session
• Average admin session is <2 hours (reviewed monthly)

Phase 6 — Detection & Alerting

Configuration prevents most attacks. Detection catches the ones that get through, and confirms that the configurations are still in place.

Required Alerts (Tier 1 — Immediate Page)

Required Alerts (Tier 2 — Email / Ticket Within Business Hours)

AWS Implementation

CloudTrail → CloudWatch Logs → Metric Filter → CloudWatch Alarm → SNS

Example: Root login alert

  Metric filter pattern:
    { $.userIdentity.type = "Root" &&
      $.userIdentity.invokedBy NOT EXISTS &&
      $.eventType != "AwsServiceEvent" }

  CloudWatch Alarm:
    Threshold: >= 1 in 1 minute
    Action: SNS → PagerDuty integration

For a multi-account setup, use AWS Config aggregator and
EventBridge cross-account event buses to consolidate.

Azure Implementation

Activity Log + Microsoft Sentinel:

  Sentinel data connectors:
    - Azure Activity
    - Microsoft Entra ID (sign-ins, audit logs)
    - Microsoft Defender for Cloud (if licensed)

  Analytic rules (built-in or custom):
    - "Sign-ins from new countries"
    - "Privileged role assigned"
    - "Conditional Access policy modified"

  Automation rules:
    - Auto-create incident in Sentinel on Tier 1 alerts
    - Auto-send to PagerDuty via Logic App

GCP Implementation

Cloud Audit Logs → Log Sink → Pub/Sub → Cloud Function → PagerDuty

  Log sink filter examples:

  Root / Super Admin login:
    protoPayload.serviceName="login.googleapis.com" AND
    protoPayload.authenticationInfo.principalEmail=
      ("super-admin-1@..." OR "super-admin-2@...")

  Service account key created:
    protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"

  Organization Policy modified:
    protoPayload.methodName="SetOrgPolicy"

Acceptance

• Tier 1 alerts page security on-call within 1 minute
• Tier 2 alerts create tickets within 15 minutes
• Alert routing tested with deliberate test events (quarterly drill)
• Alerts are not noisy — <5 false positives per week per alert
• Runbook exists for each Tier 1 alert (what to do when paged)

Phase 7 — Quarterly Access Review

The hardening configured in Phases 1-6 will drift. Phase 7 is the recurring check that confirms it hasn't, and that human access still matches business need.

What to Review (Each Quarter)

Quarterly Access Review Checklist:

  ┌─ Federation membership review ────────────────────────────┐
  │  - Each Okta / Entra ID / Auth0 group mapped to cloud      │
  │    permissions: managers re-attest member list             │
  │  - Removed members: confirmed they no longer need access   │
  │  - New members: confirmed approval trail exists            │
  └────────────────────────────────────────────────────────────┘

  ┌─ Privileged role membership ──────────────────────────────┐
  │  - Every PIM-eligible / AWS Admin permission set member    │
  │    is reviewed                                              │
  │  - Members who haven't activated in 90 days: removed       │
  │  - Active members: business justification documented       │
  └────────────────────────────────────────────────────────────┘

  ┌─ Service account / service principal review ──────────────┐
  │  - Every service account is still in use (last auth <30d)  │
  │  - Owner is still at the company and still owns it         │
  │  - Permissions are still scoped correctly                  │
  │  - Keys are within rotation policy (Phase 4)               │
  └────────────────────────────────────────────────────────────┘

  ┌─ Cross-account trust review ──────────────────────────────┐
  │  - Every cross-account role: trust still valid?            │
  │  - External ID rotated if approaching 1-year-old           │
  │  - Vendor-trust roles: vendor relationship still active?   │
  └────────────────────────────────────────────────────────────┘

  ┌─ Inactive user disable ───────────────────────────────────┐
  │  - Federated users no sign-in in 30 days: investigate      │
  │  - Federated users no sign-in in 90 days: disable          │
  │  - Disabled users 180+ days: remove from IdP               │
  └────────────────────────────────────────────────────────────┘

  ┌─ Break-glass review ──────────────────────────────────────┐
  │  - Hardware tokens in physical custody, chain of custody   │
  │    intact                                                  │
  │  - Break-glass procedure tested (annual at minimum)        │
  │  - Any use of break-glass accounts: documented and audited │
  └────────────────────────────────────────────────────────────┘

Cadence

Evidence for Auditors

Each review produces:

• A signed-off CSV of group memberships (before/after)
• A signed-off CSV of privileged role memberships (before/after)
• A signed-off list of service accounts (active / disabled / removed)
• Tickets in the access management system for each change
• A summary memo: number of accesses removed, exceptions granted, anomalies found

This becomes the evidence for SOC 2 CC6.x, HIPAA §164.308(a)(4), PCI Req 7, ISO 27001 A.9.

Acceptance

• Quarterly review scheduled on calendar with named owner
• Review template / checklist exists in runbook repo
• First review completed and evidence stored
• Auditor has access to evidence repository (read-only)
• Annual break-glass drill completed

Worked Example — Mid-Market SaaS Hardening Engagement

Profile:

Provider: AWS (multi-account, 4 accounts via Organizations)
IdP: Okta (180 employees, 25 with cloud access)
Compliance: SOC 2 + HIPAA
Workforce size: medium
Existing IAM users: 12 humans + 6 services

Before state:

• 18 local IAM users (12 humans + 6 service users) in the production account
• Root account has 2 active access keys, virtual MFA on a single person's phone
• 4 of 12 humans have no MFA on their local IAM users
• No SSO — every engineer signs in directly with IAM user credentials
• Cross-account roles between accounts have no External IDs
• No CloudTrail-based alerts on identity events
• No quarterly access review process

After applying this skill (12-week engagement):

• Phase 1 (Week 1): Root hardened. YubiKey enrolled (backup token in second safe). All 2 access keys deleted. CloudWatch alarm on root login → PagerDuty. Root email moved to aws-root@acme.com group going to 4 security team members.
• Phase 2 (Week 2): SCP attached at Organizations root enforcing aws:MultiFactorAuthPresent = true for all non-MFA-bootstrap actions. Tested with a deliberate non-MFA action — denied as expected. Okta MFA enrollment policy reviewed and tightened: FIDO2 required for admin groups.
• Phase 3 (Weeks 3-5): AWS IAM Identity Center configured. Okta federated as IdP. Four permission sets defined: ReadOnly (8hr), DevOps (4hr), Admin (1hr, JIT), Auditor (8hr, read-only including logs). Twelve Okta groups created and mapped per account. SCIM provisioning from Okta running daily. All 12 human local IAM users deleted. CLI workflow documented (aws sso login). Engineers trained in two 1-hour sessions.
• Phase 4 (Week 6): Role-trust audit. 23 IAM roles reviewed. 6 cross-account roles missing External IDs — remediated. 4 unused roles (>90 days) removed. 6 service users reviewed: 4 replaced with IAM roles attached to ECS task definitions, 2 kept as IAM users (third-party SaaS integrations that require IAM user credentials) with hardware MFA on programmatic access and 30-day key rotation.
• Phase 5 (Weeks 7-8): JIT configured. Admin permission set is now JIT-only with approval via a Slack-integrated approval bot → temporary Okta group membership for 2 hours → automatic removal. Standing admin access reduced from 8 engineers to 0 (4 break-glass exceptions reviewed quarterly).
• Phase 6 (Weeks 9-10): Alerting wired. 7 Tier 1 alerts → PagerDuty. 5 Tier 2 alerts → Jira tickets. Tested with deliberate events. Runbook authored for each Tier 1 alert.
• Phase 7 (Week 11): First quarterly access review executed. Group memberships re-attested by engineering managers. Two unused federated accounts disabled. Evidence package produced and stored in /audit/2026-q1-access-review/.
• Week 12: Documentation. Runbooks for break-glass, MFA device loss, JIT activation. SOC 2 control mapping document. HIPAA risk-assessment supporting docs. Handoff to ongoing operations.

Result:

• Zero local IAM users for humans
• Zero standing admin access
• Every cross-account trust has an External ID
• MFA enforced by SCP (impossible to bypass)
• Root hardened, alerted, locked away
• Quarterly access review on the calendar with named owners
• Evidence ready for SOC 2 Type II audit (control activities CC6.1-CC6.8 covered)

Cost:

• Engagement effort: ~8 weeks of a senior IAM architect + ~2 weeks of an internal engineering lead
• Tooling cost delta: Entra ID P2 not needed (AWS-only), $0/month additional licence cost; PagerDuty integrations on existing licence
• Ongoing operating cost: ~4 hours / quarter for access reviews + ~1 hour / month for new-joiner onboarding into Okta groups

Cross-References

Tips for Best Results

1. Always run Phase 1 (root lockdown) first. Every other phase depends on the root account being secure. If you skip it and someone compromises root, every other control is irrelevant — they can disable it.

2. Enforce MFA via SCP / Conditional Access / Org Policy — never via documentation. Humans are remarkably good at bypassing documented controls. Machine-readable guardrails cannot be skipped. If your enforcement is "we tell people to enable MFA", you don't have enforcement.

3. The break-glass procedure must be tested annually. A break-glass procedure that has never been used is a procedure that will fail when you need it. Run a deliberate drill once a year: retrieve the hardware token, sign in, perform a benign action, sign out, return the token. Document any friction.

4. One IdP is better than many. If you have Okta for SSO into SaaS apps and Entra ID for cloud federation, you have two sources of truth and twice the audit surface. Consolidate to one IdP for both workforce SaaS and cloud federation where feasible.

5. External IDs are non-negotiable for cross-account roles. When a vendor asks for a cross-account role and says "External ID is optional", insist on it. The confused-deputy attack is well-known; vendors who don't require External IDs are signalling a security maturity gap.

6. JIT > always-on, even when it's annoying. Engineers will push back on JIT admin access because it slows them down. The slow-down is the point — it makes accidental privileged actions impossible, and it makes deliberate misuse auditable. Hold the line.

7. Phase 7 (quarterly review) is what catches drift. All the other phases configure correctly. Phase 7 is what catches the engineer who got admin access for an incident 8 months ago and never had it removed. Don't skip it — it's the only phase that runs forever.

8. Sign-in alerts are not optional in any environment with PII / PHI / financial data. A root login at 3 AM on a Saturday from a country you don't operate in is the first signal of a compromised root account. If you're not alerted, you find out from the breach disclosure form 60 days later.

9. Documentation matters for the auditor — but the SCP matters for the attacker. Write both. The SCP stops the actual attack; the documentation is what the auditor can verify and what survives turnover.

10. Identity-hardening is an annual program, not a one-time project. IdPs change. Workforce changes. Cloud features change. Re-baseline annually; review quarterly; alert continuously.