IA-02 Identification and Authentication (Organizational Users)ia-2
Whether an AWS call fetches evidence for this control, and what to run. Its Rev5 baselines, the indicators that reach it and the FedRAMP guidance attached to it open below.
Partial3 of 3 recipes reach IA-02, and none is rated full — the output narrows the question, a human judgement closes it.
AWS IAM · AWS Config · AWS IAM Identity Center3 recipes · 12 calls
Collect evidence (3)
Authored AWS recipes whose output is evidence for IA-02. This mapping is this project’s opinion (overlay v3.0.0), versioned separately from the dataset — the upstream FedRAMP rules name none of these tools.
- partialAccount-wide credential report proving MFA is active per principal and that passwords/access keys are rotated within policymonthlycliiam-credential-reportIAM
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.
- partialAWS Config compliance result for the managed rule proving every IAM user with a console password has MFA enabledcontinuousconfig-ruleconfig-mfa-enabled-console-accessAWS Config · IAM
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.
- partialEvery way a workforce user can authenticate into the account, counted and named in one pass — how many IAM users and federated trusts exist, which SAML and OIDC providers are registered, whether an IAM Identity Center instance is the workforce entry path — together with the state of the two credentials that belong to no person: the root user's access key and the account's X.509 signing certificatemonthlycliidentity-sources-and-root-credential-lockdownAWS IAM · AWS IAM Identity Center · AWS Config
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.
What NIST requires of IA-02
The control statement from NIST 800-53 Rev5, verbatim. Square brackets are organization-defined parameters — yours to set, not FedRAMP's to dictate.
Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.
NIST SP 800-53 Rev5 catalog 5.2.0, from usnistgov/oscal-content at 78650f0. The FedRAMP dataset carries no control text; this is borrowed and pinned.
Rev5 baseline membership
Membership is the whole relationship — a baseline is a set of control ids. Class A carries no baseline at all. The Low/Moderate/High labels are an interpretation from control counts, not a dataset fact.
KSI indicators reaching this control (2)
Under 20x, these indicators are how this control is demonstrated — automated KSI evidence stands in for narrative control evidence.
- IAMKSI-IAM-APMAdopting Passwordless Methods
Secure passwordless methods are used for user authentication and authorization when feasible, otherwise strong passwords with phishing-resistant MFA is used.
- IAMKSI-IAM-ELPEnsuring Least Privilege
Identity and access management measures are used and persistently reviewed to ensure each user or device can only access the resources they need.
FedRAMP guidance & parameters
Where you read the rule. Guidance names an FRR document, never a clause, so the links below offer the whole document and leave the reading to you.
- Multi-factor authentication must be phishing-resistant. In accordance with current CISA Guidance. Current CISA guidance can be found here: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
Pages exist for the 209 controls reached by at least one KSI. Baseline-only controls are the orphans on /coverage. Control titles and full text live in the NIST catalog, not this dataset.