IA-2 Identification and Authentication (Organizational Users) is the control behind most login questions in a security review. Its base statement is short: uniquely identify and authenticate organizational users, and associate that unique identification with processes acting on their behalf. The enhancements are where multi factor authentication lives.
800-53 binds US federal systems, and reaches vendors through contracts. For a small or mid size company it is a reference that mirrors what customers ask for in questionnaires. Whether a given customer or auditor accepts a particular mapping to another framework varies, so check their source.
What it means in practice
Three ideas sit inside the sentence.
First, unique. No shared logins for people. Each person has an identifier that points to them alone.
Second, authenticated. Something proves the person is the owner of the identifier.
Third, associated with processes. When a script or job acts for a user, the action traces back to that user.
NIST defines organizational users as employees and individuals treated as equivalent, such as contractors and guest researchers. The requirement applies to every access except those explicitly documented under AC-14 as allowed without identification.
The enhancements that auditors ask about
- IA-2.1 Multi-factor Authentication to Privileged Accounts
- IA-2.2 Multi-factor Authentication to Non-privileged Accounts
- IA-2.3 Local Access to Privileged Accounts
- IA-2.4 Local Access to Non-privileged Accounts
- IA-2.5 Individual Authentication with Group Authentication
- IA-2.6 Access to Accounts, Separate Device
- IA-2.7 Network Access to Non-privileged Accounts, Separate Device
- IA-2.8 Access to Accounts, Replay Resistant
In practice IA-2.1 and IA-2.2 are the ones that decide most audits. Privileged accounts first, then everyone.
Evidence to collect
- Identity provider export of all users with MFA enrollment status.
- The policy setting that enforces MFA, with its scope and any exclusions.
- A list of exceptions with an owner, a reason and an expiry date.
- A sample showing a shared account was replaced by named accounts.
- Break glass account procedure and the log of its use.
- Screenshots are weak. Prefer exports with a timestamp.
Click through it at your own pace, or open it full screen.
Common gaps
MFA enforced in the portal but not on legacy protocols such as basic auth for email or older VPN clients. Service accounts counted as users with no owner. Contractors in a separate directory with no MFA policy. A break glass account with a password that has not changed in years. Shared admin accounts for cloud consoles.
How to implement it
Centralize sign in through one identity provider. Enforce phishing resistant factors for privileged roles where you can, and any strong factor for everyone else. Turn off legacy authentication. Replace shared accounts with named ones and use a vault for the few that must remain. Review the MFA coverage report monthly and file it.
Quick check
What does "unique identification" rule out?
Shared logins for people. Each person needs their own identifier so actions are attributable to them.
Which enhancements require MFA?
IA-2.1 for privileged accounts and IA-2.2 for non privileged accounts.
