IA-12(2): Identity Evidence

IA-12(2): Identity Evidence requires you to make your Registration Authority (RA) collect and review identity evidence (for example, government-issued ID or equivalent proof) before issuing or linking a digital identity to an individual. Operationalize it by defining acceptable evidence, training RA staff, building an auditable workflow, and retaining proof that evidence was presented and verified. ¹

Key takeaways:

• Put a Registration Authority workflow in writing: what evidence is acceptable, who checks it, and when issuance must stop.
• Make verification auditable: logs, screenshots/records of the ID proofing step, and approval traces tied to the identity record.
• Control scope tightly: apply to employees, contractors, admins, and anyone receiving a credential for systems handling federal data.

The ia-12(2): identity evidence requirement is easy to misunderstand because teams assume “HR onboarding” or “SSO account creation” already proves identity. IA-12(2) is narrower and stricter: it expects the Registration Authority function (the people or system that approves identity enrollment) to require identity evidence to be presented before a digital identity is registered or a credential is issued. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat IA-12(2) as a gating control in the identity lifecycle: no evidence, no registration; no registration, no credential. That gating step must be consistent across hiring locations, remote onboarding, privileged accounts, and third-party workforce scenarios. You also need to retain artifacts that prove it happened for specific individuals, not just a policy statement.

This page gives requirement-level implementation guidance: who owns it, where it shows up operationally, what evidence auditors ask for, common failure modes, and a practical execution plan you can run without rewriting your entire IAM program. Citations are limited to the NIST control text sources provided. ²

Regulatory text

NIST requirement (IA-12(2)): “Require evidence of individual identification be presented to the registration authority.” ¹

What the operator must do

• Designate or define the Registration Authority (RA) function for your environment (a team, role, or managed service).
• Require that the RA collects and reviews identity evidence before the RA approves initial registration (or equivalent enrollment) for an individual.
• Ensure the RA step is documented and repeatable, and that you can show proof the evidence was presented for each registration event you test. ¹

Plain-English interpretation (what IA-12(2) means in practice)

IA-12(2) is a control about identity proofing at the moment of enrollment. Your organization must not create a trusted “digital person” (an identity record that can be authenticated and authorized) unless the RA has seen appropriate identity evidence for that individual. ¹

This is not only a policy requirement. Assessors typically test whether:

• your workflow forces evidence collection,
• the RA actually performs the check, and
• your records prove the check occurred for a sample of identities.

Who it applies to (entity + operational context)

Entities

• Federal information systems and contractor systems handling federal data implementing NIST SP 800-53 Rev. 5 controls. ¹

Operational contexts where IA-12(2) commonly applies

Treat IA-12(2) as applicable anywhere you enroll an identity that will receive credentials or access:

• Employee onboarding (especially remote hiring).
• Contractor and third-party workforce onboarding (staff augmentation, MSP operators).
• Privileged / administrative account issuance (domain admins, cloud admins).
• Break-glass or emergency accounts (create-only-when-needed still needs identity evidence).
• Identity linking events (merging duplicate identities; re-proofing after legal name change).
• Re-issuance after suspicious activity or identity record compromise (your policy can require re-proofing triggers; IA-12(2) sets the baseline expectation that evidence is presented to the RA at registration). ¹

What you actually need to do (step-by-step)

Step 1: Define the Registration Authority (RA) function and boundaries

Create a short RA designation statement that answers:

• Who can approve identity registration? (Role names, not individuals.)
• Which systems are “in scope” for RA-controlled registration? (Your authoritative identity source, IAM, HRIS-to-IAM bridge, ticketing.)
• Which identity types are covered? Employees, contractors, interns, service desk temps, third-party admins. ¹

Practical tip: If you outsource onboarding to a third party, you still need an RA function contractually. Make the third party follow your evidence rules and give you audit artifacts.

Step 2: Set “acceptable identity evidence” rules (don’t overcomplicate)

Write a procedure section that lists:

• Accepted evidence types (government-issued photo ID, passport, other authoritative documents your organization accepts).
• Whether copies are allowed or whether the RA must view originals or verified digital equivalents.
• Remote onboarding method (live video verification, trusted digital ID verification process, or in-person check).
• Minimum required attributes to match (legal name, DOB, photo match, document validity period, etc.).

IA-12(2) does not prescribe document types in the provided excerpt, but auditors will expect you to be specific so RA actions are consistent. Anchor your choices in risk: higher assurance for privileged access and sensitive systems. ¹

Step 3: Build the workflow gate: “no evidence, no registration”

Implement a control point that prevents registration approval unless evidence is recorded as “presented and verified.” Common patterns:

• Ticket-based RA approval: onboarding ticket cannot be closed without an “Identity evidence verified” checklist item and approver signature.
• IAM/IGA workflow: an enrollment request requires an RA step with a mandatory field confirming evidence review; system logs capture who approved and when.
• HRIS-triggered flow: HR initiates, but RA verifies evidence before the identity becomes active in IAM.

Make the gate explicit for:

• initial registration,
• re-activation after termination (if you allow it),
• identity merges or corrections that change core identity attributes. ¹

Step 4: Train the RA and service desk, and lock down who can bypass

Write training that covers:

• how to inspect evidence,
• red flags (mismatched names, expired document),
• what to do when evidence is missing (hold the request; escalate),
• how to handle edge cases (contractors onboarded by a third party, urgent access requests).

Then enforce:

• only RA-designated roles can approve registration,
• privileged groups cannot self-approve, and
• emergency pathways still produce evidence artifacts after the fact (if your policy allows a short exception window, document it and monitor it; keep exceptions rare and reviewed). ¹

Step 5: Decide what to retain and for how long (minimize sensitive retention)

IA-12(2) requires evidence be presented to the RA; it does not explicitly require storing copies of IDs in the excerpt provided. A strong approach is to retain:

• a record that evidence was presented and verified,
• who verified it,
• what type of evidence was reviewed,
• date/time,
• link to the identity record and enrollment request.

If you retain images of IDs, treat them as sensitive data and apply strict access controls and retention limits consistent with your internal policies and privacy obligations.

Step 6: Make it assessable: test samples and close gaps

Run a readiness test:

• pull a sample of newly created identities across employees and contractors,
• show the RA evidence verification record for each,
• confirm the RA approver is authorized,
• confirm timestamps align (verification before credential issuance). ¹

A practical way to keep this continuously ready is to track IA-12(2) as a control with a defined owner, procedure, and recurring evidence artifacts in your GRC system; Daydream can help you map the requirement to a control owner and keep the evidence requests consistent cycle to cycle. ¹

Required evidence and artifacts to retain (audit-ready)

Use this table as your evidence checklist.

Artifact	What it proves	Good format	Owner
RA policy/procedure for identity evidence	Requirement is defined and standardized	Approved document with version control	IAM / Security GRC
RA role designation + access list	Only authorized staff act as RA	Role matrix; group membership export	IAM
Enrollment/registration workflow record	Evidence was presented before registration approval	Ticket/workflow record with required fields	Service Desk / IGA
RA approval log	Who approved and when	System audit log export	IAM
Sampled identity files (references)	Traceability from person → identity → approval	Identity record ID + linked ticket	IAM
Exception records (if any)	Exceptions are controlled and reviewed	Exception register + approvals	GRC

Common exam/audit questions and hangups

Expect assessors to ask:

1. “Who is your Registration Authority?” If you answer with a team name but can’t show role membership and responsibilities, you will stall.
2. “Show me evidence for these 10 identities.” They will pick privileged admins and contractors.
3. “Was verification done before credentials were issued?” Timing matters; backfilled checkboxes look weak.
4. “Do third-party onboarding partners follow the same RA evidence rules?” Contracts and artifacts matter if the RA function is outsourced.
5. “What happens for remote hires?” If your procedure only supports in-person evidence checks, you may have an operational gap. ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating HR onboarding as “identity evidence.”
   Fix: Require an RA checkpoint that is explicitly tied to system identity registration, not only employment eligibility steps.

2. Mistake: No clear RA role; anyone in IT can create accounts.
   Fix: Restrict account creation/approval permissions and document RA responsibilities.

3. Mistake: Storing ID images without a retention/access plan.
   Fix: Prefer “verification attestation + evidence type” unless you have a defined need to store images; if you store images, restrict access and set retention.

4. Mistake: Contractors created via email requests with no evidence.
   Fix: Force contractor onboarding through the same enrollment workflow, and require the staffing firm (third party) to provide evidence to the RA.

5. Mistake: Evidence exists, but you can’t retrieve it per identity.
   Fix: Build traceability: identity record must link to the RA verification record. “We check IDs” without per-user artifacts fails quickly in exams. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for IA-12(2), so this page does not cite specific enforcement outcomes.

Operationally, weak identity evidence controls create predictable failure modes: fraudulent account creation, unauthorized access via “ghost” or duplicate identities, and elevated insider risk because the system cannot reliably bind credentials to a real individual. IA-12(2) reduces those risks by forcing an evidence-based enrollment step that is auditable. ¹

Practical execution plan (30/60/90-day)

First 30 days (stabilize and define)

• Name the RA owner and publish RA responsibilities.
• Write the “acceptable identity evidence” procedure for employees and contractors.
• Identify all enrollment paths (HR-driven, service desk, direct admin creation, third-party managed).
• Add the gating checkpoint to the highest-risk path first: privileged/admin accounts. ¹

By 60 days (implement workflow + evidence)

• Implement mandatory fields/checklists in ticketing or IGA workflow.
• Restrict who can approve registration to RA roles.
• Train RA staff and service desk on the new flow and exception handling.
• Start a lightweight monthly sample review to confirm artifacts exist and timestamps align. ¹

By 90 days (scale and prove operational effectiveness)

• Extend the same RA evidence gate to all identity types in scope (employees, contractors, interns, third-party admins).
• Add contract language for third parties performing onboarding or acting as RA.
• Create an assessor-ready evidence packet: policy, RA roster, workflow screenshots, and a sample set of identity records with linked RA verification.
• In Daydream, map IA-12(2) to the control owner, procedure, and recurring evidence artifacts so audits pull from a repeatable checklist rather than a one-time scramble. ¹

Frequently Asked Questions

Does IA-12(2) require us to store copies of government IDs?

The excerpt requires evidence be presented to the Registration Authority; it does not state you must retain ID images. Retain an auditable record that evidence was presented and verified, and only store images if your internal policy requires it. ¹

Who can be the Registration Authority in a small organization?

The RA can be a small set of trained staff (often HR + IAM/security) as long as the role is defined and only authorized personnel can approve registration. Auditors will test that the RA function is consistent and evidenced. ¹

How do we handle remote hires where we can’t inspect physical IDs in person?

Define an approved remote process where the RA still receives and reviews identity evidence through a controlled method, and retain proof of the verification step. The key is that evidence is presented to the RA before registration approval. ¹

Does this apply to contractors provided by a staffing agency (third party)?

Yes, if the contractor receives a digital identity and credentials in your environment, the RA must require identity evidence for that individual. If the staffing agency performs the check, document it contractually and retain artifacts you can produce in an audit. ¹

What will an auditor sample to test IA-12(2) quickly?

They usually sample newly created identities, privileged/admin accounts, and contractor accounts, then ask for the RA verification record tied to each identity. They also check that verification happened before credential issuance. ¹

We already have MFA and strong passwords. Why does IA-12(2) still matter?

MFA strengthens authentication after an identity exists; IA-12(2) addresses the upstream risk of enrolling the wrong person or a fabricated identity. If enrollment is weak, strong authentication can still protect the wrong account holder. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON