IA · Plan wizard

Identification and Authentication Plan

Documents how the system identifies users, devices, and services and verifies their authenticators. Covers the controls of the IA family in NIST SP 800-53 r5 and aligns with NIST SP 800-63 (Digital Identity Guidelines) and FIPS 140 (cryptographic modules).

Load draft

1 System metadata

System name Full official name of the information system.

System acronym / short name Short identifier used in headings and references.

System owner Role or named individual accountable for the system.

Information System Security Officer (ISSO)

Information System Security Manager (ISSM)

ATO date / target ATO date

Environment

Classification level

System boundary description Describe what falls inside the authorization boundary - components, services, networks, data flows.

2 Baseline

Pick the baseline that controls system applicability Determines which controls in this family appear in your plan.

3 Identification and Authentication approach

Approach basics → §4.x

Identity provider, supported authenticators, and target assurance levels.

Primary identity provider (IdP) The platform that authenticates users and issues identity assertions (e.g., Azure AD / Entra ID, Okta, Ping, Keycloak, AWS IAM Identity Center, ADFS).

Scope of MFA enforcement Population required to use MFA. Federal systems handling CUI require AAL2+; privileged often AAL3.

Target Identity Assurance Level (IAL) Per NIST SP 800-63A. Federal systems handling CUI typically require IAL2; classified often IAL3.

Target Authenticator Assurance Level (AAL) Per NIST SP 800-63B. Federal CUI typically AAL2; privileged or classified AAL3.

Identifier management strategy (one-line) Brief phrase summarizing how identifiers are issued and reused. Detail goes in the dedicated sub-section.

Identifier Management → §4.x

How identifiers are assigned, formatted, reused, and disabled (IA-4).

User identifier format Format / convention for usernames (e.g., 'firstname.lastname@org', 'EDIPI for DoD', 'email address from authoritative source').

Uniqueness enforcement How identifier collisions are prevented across the user lifecycle, and what disambiguates two people with the same name.

Identifier reuse policy Best practice: never reuse. Federal systems often require minimum 1-2 years of dormancy before reuse, if any.

Identifier disable cadence on departure How quickly an identifier is disabled after the user leaves (e.g., '24 hours after HR notification'; 'immediate for involuntary terminations').

Device identifier strategy How devices are assigned identifiers (e.g., 'Hostname format <env>-<role>-<n>; X.509 cert with hostname in CN; AD computer object with FQDN matching cert').

Service / machine account identifier strategy How service accounts are named (svc- prefix, app-svc-<name>, managed identity, etc.) and how they're distinguished from human users in logs.

Authenticator Management → §4.x

Issuance, distribution, rotation, revocation of authenticators (IA-5).

Initial authenticator issuance process How a new user receives their first authenticator. In-person handoff for hardware tokens, signed package for PIV cards, etc.

Authenticator distribution method Secure channel used to deliver authenticators (encrypted email with separate password, in-person, registered mail).

Rotation / re-issuance cadence By authenticator type (e.g., 'PIV cards every 6 years per FIPS 201; service-account passwords every 60 days; FIDO2 keys lifetime').

Revocation workflow How a compromised or surrendered authenticator is revoked across all systems. Time bound (e.g., 'within 4 hours of report').

Password / passphrase complexity Length, allowed character classes, breach-list checking, anti-pattern rules. Per NIST SP 800-63B, length matters more than complexity rules.

Password storage method Per NIST SP 800-63B, memorized secrets must be salted and hashed using a memory-hard function.

Multi-Factor Authentication Strategy → §4.x

When MFA is required, methods preferred, and exception handling.

MFA scope details Specific scenarios / actions / populations requiring MFA beyond the high-level scope in §4.1.

Preferred MFA method Method recommended to users by default. Federal systems should default to hardware-key when feasible (per OMB M-22-09 zero-trust guidance).

Phishing-resistance level Per OMB M-22-09, federal systems should adopt phishing-resistant MFA. Document where you stand on the journey.

MFA fallback / recovery method What happens when a user loses their primary authenticator. Help-desk verification process, backup codes, or in-person re-issuance.

MFA exceptions process Rare scenarios where MFA cannot be enforced (legacy system, embedded service). Time-bound exception register; cross-reference §4.5 of CM Plan if relevant.

Device Identification and Authentication → §4.x

How devices authenticate to the system (IA-3).

Device authentication mechanism How devices identify themselves: X.509 client certificates, MDM-issued certs, EAP-TLS, MAC binding (last resort), MFA-bound device identity.

Device certificate authority / issuer PKI / CA that issues device certificates (e.g., 'Internal CA on enterprise PKI', 'Microsoft Intune-issued device cert').

Device revocation mechanism How a lost / decommissioned device is removed from authentication. CRL / OCSP / cert-bound short-lifetime tokens.

Service / Machine Authentication → §4.x

How services and automated processes authenticate (IA-9).

Service authentication mechanism Mechanism: managed identity (cloud-native), workload identity federation, mTLS, signed JWT, API key (last resort), service principal.

Service-credential storage / vaulting Where service credentials live (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk).

Service-credential rotation Cadence + automation for rotating service credentials. Short-lived ephemeral credentials (workload identity) are best practice.

Service account ownership model How each service account is assigned to a human owner / role for accountability. Quarterly review against ownership register.

Non-Organizational Users → §4.x

Federation, external partner identities, and public users (IA-8).

External user populations served

Federal employees (other agency) Contractors Industry partners (federation) Citizens (public) Vendor support staff None — internal only

Federation partners

Suggested:

External identity providers federated with the system.

IAL/AAL required for external users Assurance levels enforced for non-organizational users — often differ from internal scope.

Attribute release policy (federation) Which attributes the external IdP must assert for the user to be authenticated (subject, email, group memberships, MFA satisfied claim).

Adaptive and Re-authentication → §4.x

Risk-based authentication and re-authentication triggers (IA-10, IA-11).

Risk signals informing adaptive auth

IP / geo anomaly New device Impossible travel Threat intelligence match Behavior anomaly (UEBA) Time-of-day deviation MFA fatigue pattern detected Compromised credential indicator

Signals that elevate authentication strength (step-up MFA) when a risk threshold is crossed.

Adaptive authentication engine Tool / service evaluating risk signals (e.g., 'Okta Adaptive MFA', 'Azure AD Conditional Access', 'custom risk engine').

Re-authentication triggers

Time-bound (after N hours) Privilege elevation request Sensitive operation (delete / export) Cross-tenant or external system access Risk score threshold crossed Cryptographic re-handshake

Maximum session duration before forced re-auth Hard cap on session length before user must re-authenticate (per AAL2: 12h interactive / 30 days non-interactive; per AAL3: 12h / 18h).

Identity Populations Supported → §2.x

Numerical scope of who authenticates to this system.

Internal user count (approximate)

External user count (federated / public)

Authenticated device count

Service / machine identity count

Authentication Metrics & KPIs → §6.x

Metrics tracked to demonstrate IA control effectiveness over time.

Tracked metrics

Suggested:

Cross-references to other RMF artifacts → §7

Where this plan plugs into the broader RMF package.

SSP section reference Where in the SSP the IA control implementations are summarized (e.g., 'SSP §13.4').

POA&M ID prefix for IA findings Convention for IA-related POA&M items (e.g., 'POAM-IA-').

AC plan cross-reference Where the AC plan consumes IA outputs. AC delegates the underlying authenticator strength and identity proofing to IA.

AU event handoff How authentication events (success / failure / step-up) flow into the AU pipeline. SIEM index, log source, retention.

CA-7 continuous-monitoring strategy reference Pointer to the CA-7 monitoring strategy document tying IA continuous-monitoring metrics to the broader ConMon plan.

4 Per-control implementation

Pick a baseline in section 2 and the applicable controls will appear here. Each control gets a card with the official text, related controls, linked CCIs, and fields for your implementation status, narrative, responsible role, and evidence.

5 Document metadata

Document version

Document author

Publication date