Trackr.Live The landing site for Trackr Services
§ Trackr.Live

IA — Identification and Authentication

Identification and Authentication is the family that proves you are who you claim to be before Access Control decides what you are allowed to touch. That split is the whole point, and it is the thing most SSP prose gets wrong. IA establishes the identity and the strength of the binding to it. AC takes that proven identity and resolves it against a set of authorizations. If your narrative says “users authenticate to the application and are granted role-based access,” you have just smeared an IA control and an AC control into one sentence, and an assessor reading carefully will ask you to pull them apart. IA is also the family with the deepest federal-specific machinery behind it, because the identity backbone for federal and DoD systems is PIV and CAC, and the strength language comes from a whole separate document set in SP 800-63.

A schematic of an identity claim being proven: a credential token presenting to a verifier, a second factor resolving alongside it, and a validated identity passing forward into a separate set of authorization gates.
IA is a control catalog family from SP 800-53, not a step in the RMF. The RMF is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. IA controls get pulled into the system at Select off the 800-53B baseline, get real implementations and SSP narratives at Implement, and get graded at Assess. When IA-2 multi-factor evidence shows up in a SAR, that evidence is what the assessor sampled at Assess, and any authenticator that did not meet the stated assurance level lands in the POA&M and rides into continuous monitoring.

What’s in the family

In Rev 5 the IA family runs IA-1 through IA-12, and no control in it was withdrawn. The one people misread is IA-9. IA-9, Service Identification and Authentication, is an active Rev 5 control that simply is not allocated to any baseline (no Low, Moderate, or High), so it only enters a system through an overlay or tailoring decision, typically on service-oriented architectures that have to authenticate services to each other. Active but unbaselined is not the same as withdrawn, and treating it as gone is its own mistake. The other thing worth getting right up front: IA-3 is Device Identification and Authentication, and non-organizational users is IA-8. A lot of older reference material swaps those two, and a swapped pair in your control narrative is an easy finding.

The controls that carry the weight:

  • IA-1, Policy and Procedures. The family’s documented policy and the procedures under it. Same -1 shape as every other family, same role as the thing every other IA control inherits its existence from.
  • IA-2, Identification and Authentication (Organizational Users). The base requirement to uniquely identify and authenticate your own users. The real weight lives in the enhancements. IA-2(1) requires MFA to privileged accounts, IA-2(2) requires MFA to non-privileged accounts, IA-2(8) demands replay resistance, and IA-2(12) is acceptance of PIV credentials. Rev 5 consolidated the old Rev 4 split of (1) through (4) across privileged/non-privileged and local/network into the cleaner (1)/(2) shape, so a narrative quoting the four-way split is dated.
  • IA-3, Device Identification and Authentication. Authenticating devices, not people, before they connect. Think 802.1X with certificate-based machine auth. Often light on a pure datacenter system, a real project on anything with field endpoints.
  • IA-4, Identifier Management. The lifecycle of the identifier itself, distinct from the account it attaches to. This is where the identifier-reuse window lives: how long before a retired username or UID can go to someone new.
  • IA-5, Authenticator Management. The biggest control in the family by surface area, and one that splits along a fault line. IA-5(1) is password-based. IA-5(2) is public-key-based, the PIV and CAC certificate path. Most of the family’s day-to-day friction is here.
  • IA-6, Authentication Feedback. Obscuring feedback during authentication so an onlooker cannot harvest it. The masked-password-dots control. It is not about telling the user whether login succeeded, which is the inversion a lot of bad summaries make.
  • IA-7, Cryptographic Module Authentication. Authentication to a cryptographic module consistent with FIPS 140-3 (and 140-2 modules still in their validation sunset).
  • IA-8, Identification and Authentication (Non-Organizational Users). Everyone who is not your own org’s user. IA-8(1) is acceptance of PIV credentials from other agencies, IA-8(4) is use of defined profiles for federation.
  • IA-11, Re-Authentication. Forcing the user to prove identity again under defined conditions (role change, after a fixed period, on privilege escalation). The control everyone forgets to actually configure.
  • IA-12, Identity Proofing. The marquee Rev 5 addition. Proving a real-world identity before issuing credentials at all, with IA-12(2) on identity evidence and IA-12(4) on in-person validation. Maps directly to SP 800-63A identity assurance.

IA-10 (Adaptive Authentication) is in the catalog too but allocated to no baseline; like IA-9 it only arrives by overlay or tailoring, and it shows up on systems doing risk-based step-up auth.

SP 800-63, PIV, and where the strength language actually lives

800-53 tells you to use MFA. It does not, by itself, tell you how strong. That language is in SP 800-63, split three ways: 800-63A is identity proofing and gives you the IAL (identity assurance levels), 800-63B is authenticators and gives you the AAL (authenticator assurance levels), and 800-63C is federation and gives you the FAL. IA-12 maps to IAL. IA-2’s MFA enhancements map to AAL2 and AAL3. IA-8’s federation profiles map to FAL. When an assessor asks “what assurance level is this credential,” they are asking you to connect your 800-53 IA controls to the 800-63 number, and a narrative that never mentions IAL/AAL is missing the grounding the family was built on.

The federal identity backbone underneath all of this is FIPS 201, which defines PIV. CAC is the DoD instantiation of PIV. A PIV or CAC card is a hardware authenticator carrying PKI certificates, which is why IA-5(2) public-key authenticator management and IA-2(12) PIV acceptance are the controls that actually describe how most federal users log in. If your system accepts smart-card logon, your IA-5 narrative is a PKI-management story, not a password-rotation story.

That fault line is where I will plant the contestable flag: 800-63B retired periodic password rotation and forced composition rules, and IA-5 implementations that still mandate 60-day expiry and a special-character regex are running a posture NIST walked away from. 800-63B is explicit that you should not require arbitrary periodic change absent evidence of compromise, and should not impose composition rules that just push users toward Summer2026!. Plenty of org-level IA-5 policy still bakes in the old rotation, usually because a GPO written in 2014 was never revisited and nobody wants to be the person who relaxed a password rule. The control text supports the modern posture; the inertia does not. I would fix the policy before an assessor asks why you enforce a practice the standard now argues against. The counter-argument is fair, though: if your overlay or your AO explicitly requires rotation, the overlay wins and you document it.

Baselines and where the controls come from

The baselines live in SP 800-53B, not in the catalog. FIPS 199 sets categorization, FIPS 200 sets the floor, 800-53B turns the impact level into a starting control set, and CNSSI 1253 overlays it for national-security systems. The thing that changed the IA conversation in Rev 5: MFA is baseline even at Low. IA-2(1) and IA-2(2) are allocated starting at Low, so the old “we’re only Low, we don’t need MFA” position is gone. IA-12 and its enhancements escalate as you climb, with in-person proofing landing on the higher baselines.

Deeper: identifier management is not account management.
IA-4 and AC-2 get conflated constantly, and the boundary matters because an offboarding gap can hide in the seam. AC-2 is the account: request, provision, disable, remove, recertify. IA-4 is the identifier bound to that account: the username, the UID, the certificate subject. The classic failure chain runs PS-4 (personnel termination) into AC-2 (disable the account) into IA-4 (and don’t reissue that person’s identifier to someone new before the defined reuse window expires). Disabling the account satisfies AC-2. It does nothing for IA-4 if your directory recycles UIDs and a new hire inherits an old subject DN that still matches a cached authorization or an old certificate mapping. On a system with smart-card logon and certificate-to-account mapping, identifier reuse is a real attack surface, not a paperwork distinction, and the SSP has to show that the AC-2 disable and the IA-4 reuse policy are wired together rather than living in two different teams’ procedures.

Control Typical first live at What an assessor actually checks
IA-2 Low Unique IDs per user, no shared admin logins. Sample for generic accounts.
IA-2(1)/(2) Low MFA actually enforced for privileged and non-privileged access, not just available. Try to authenticate single-factor.
IA-4 Low Identifier reuse window documented and enforced; cross-check against AC-2 disable evidence.
IA-5(1) Low Password policy config matches the SSP; check whether it still mandates retired rotation rules.
IA-5(2) Moderate PKI path: cert validation, revocation checking (OCSP/CRL), trust anchors.
IA-6 Low Authentication feedback obscured at the point of entry (masked input).
IA-7 Low Crypto modules carry a current FIPS 140-3 (or in-sunset 140-2) validation.
IA-8 Low Non-org / federated identity handled, PIV-I or partner credentials accepted per defined profile.
IA-12 Moderate Identity proofing process and evidence retained at the stated IAL.

The “first live at” column is directional. Your overlay moves it, and FedRAMP or a DoD overlay routinely pulls IA enhancements above the bare 800-53B allocation.

Where it actually goes wrong

MFA that is enabled but not enforced. The most common IA-2 finding is not absent MFA, it is MFA you can route around. The capability is turned on, the SSP says “multi-factor authentication is required,” and then there is a service account, a legacy VPN profile, or a break-glass path that accepts a password alone. An assessor does not read the policy and move on; they try to authenticate with one factor and see what happens. If a single-factor path exists anywhere into a privileged interface, IA-2(1) is Other Than Satisfied no matter what the narrative claims.

IA-5 PKI brittleness. Smart-card auth fails in the boring places: revocation checking. If OCSP is unreachable or the CRL is stale, your system either fails open (accepting a possibly-revoked cert, which is the finding) or fails closed (locking out valid users, which is the outage). Trust-anchor management is the other one. A PIV chain that validates against the Federal Common Policy CA today breaks the day a cross-certificate rolls over and nobody updated the trust store. None of this shows up in a policy review. It shows up when you test a revoked card against the login path, which most self-assessments skip.

IA-11 re-authentication that was never configured. The control gets a one-line narrative and zero implementation. Re-authentication on role change and after a defined idle period is the part that quietly never got turned on, because session defaults rarely enforce it and nobody filed the ticket. Worth checking your session config against the SSP claim before an assessor does.

Identity proofing as a paper trail. IA-12 is new enough that a lot of systems describe a proofing process the issuing authority runs and assume that satisfies it. Maybe it does, if the assurance level matches and the evidence is retained. But “HR verifies identity at onboarding” is not IAL2 proofing with retained identity evidence, and the gap between what your sponsor org does and the IAL your system claims is what an assessor will probe.

Artifacts

IA implementations land in the same three places as everything else. The SSP carries the per-control narrative, and for IA that narrative has to name the assurance levels, the authenticator types, and the PIV/CAC path in specifics rather than catalog paraphrase. The SAR is the assessor’s verdict, and for IA it usually includes actual authentication testing, not just a policy read. The POA&M holds the single-factor path you forgot about and the stale CRL. The fastest way to fail an IA assessment is an SSP that says “the system uses multi-factor authentication” and nothing else. The assessor already knows the catalog says to. What they want is which factors, at what AAL, over which path, validated how.

If your IA narrative could be pasted into any other system’s SSP unchanged, it is too generic to pass, and for this family the tell is the absence of any 800-63 or PIV specificity at all.

Sources

Adjacent material on this site