KSI-IAM-APMAdopting Passwordless Methods

Assert mfa_active=true for every password_enabled=true principal, and (now - access_key_N_last_rotated) <= 90d for every active key. generate-credential-report is async; poll get-credential-report until State=COMPLETE (report is regenerated at most every 4 hours). mfa_active is TRUE for a virtual TOTP device as well as a FIDO key, and the CSV covers IAM users and the root user only — a human confirms from the identity provider's own report that console authentication is phishing-resistant (the IA-02 (01)/(02) guidance) and that federated Identity Center or external-IdP sign-ins are covered elsewhere. The 90-day threshold is CIS Benchmark 1.14's, not FedRAMP's. Filed under IA-02 and IA-05 base: key age tests IA-05 (g), not AC-02 (01)'s automated account management or IA-05 (01)'s password rules.

Substitute your deployed rule name if it differs from the default. An empty NON_COMPLIANT result is the pass condition. Pair with the IAM_USER_MFA_ENABLED rule to also catch programmatic users. MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS is COMPLIANT for any enabled device, including a virtual TOTP app; whether the factor is phishing-resistant (the IA-02 (01)/(02) guidance), and whether workforce console access runs through IAM users at all rather than IAM Identity Center, are judgements outside this output — filed under IA-02 base for that reason, and nothing here partitions privileged from non-privileged accounts.

Strongest evidence for non-user auth is the absence of long-lived keys entirely (prefer IAM roles / temporary credentials). Where keys must exist, this rule proves rotation. Set maxAccessKeyAge to your policy (<=90d). The rule's verdict is only as strong as the maxAccessKeyAge an operator set, and the output does not carry the parameter — a human confirms it matches the SSP's rotation period. Root-user access keys are outside the rule by AWS's documented limitation. Filed under IA-05 base: key age tests IA-05 (g), not AC-02 (01).

This enumerates the authentication paths and closes the credentials that belong to nobody. What it cannot do is the word IA-02 turns on: unique. No API reports that an IAM user is one named human rather than a login three engineers share, or that a federated subject maps one-to-one onto a person on the roster — that binding lives in the personnel record and the joiner/mover/leaver process, and a reviewer establishes it by joining this output against the account inventory (see the AC-02 account-authorization-details recipe), not by reading this output alone. Rated partial for that reason: the authentication half is decided here outright, the identification half is not. Providers counts SAML and OIDC providers together, so the two list calls are what tell you which is which. An account with Users at 0 and one Identity Center instance is the strong shape — no standing workforce credentials at all — and an account with both is the one worth explaining. Substitute nothing here: every command runs as written. The two AWS Config rules are periodic and evaluate global IAM resource types, so deploy them in exactly one Region; adding them in several does not add coverage and does add duplicate evaluations.

Drive both loops from the list calls, not from whatever the describe calls happen to return, so a pool nobody configured is a visible failure rather than an absent row. AllowUnauthenticatedIdentities is the assertion that carries the control: an identity pool with guest access on hands AWS credentials to a caller who never authenticated, which is precisely the population IA-08 exists to exclude. It is the one setting here that can silently undo everything upstream, which is why the cadence is weekly rather than quarterly. MfaConfiguration is asserted against ON rather than merely not-OFF on purpose. OPTIONAL does not require anything — it delegates the decision to the client application, so a pool set to OPTIONAL and an application that never prompts is indistinguishable from OFF in this output. Scope the loop to the pools that actually serve non-organizational users: a pool used only as a directory for an internal service has no external population and asserting ON over it is a finding about the wrong thing. That scoping sentence is why this recipe is partial rather than full, and the reason is worth stating plainly. Both assertions range over lists, and no AWS call reports which directory serves the external population — or whether external users reach the system through Cognito at all rather than through an API Gateway authorizer or an ALB fronting an IdP. On an account with no user pools and no identity pools, both assertions are vacuously true and the control is unevidenced. The second gap is the control's first verb: MfaConfiguration decides how strongly an external identity authenticates, never that it is UNIQUE to one human, and a pool with MFA ON and self-service sign-up admits as many accounts per person as they care to open. Both gaps close with a human naming the external population and the registration path, which is the definition of partial. What this does not reach is the external identity provider's own registration and proofing — whether the SAML or OIDC provider behind SamlProviderARNs vetted the human before issuing them a subject. That is IA-08(1), (2) and (4) territory and is evidenced by the provider's assurance-level attestation, not by any AWS call.