Identity Proofing | Identity Evidence

To meet the identity proofing | identity evidence requirement in NIST SP 800-53 Rev 5 IA-12(2), you must require each person to present acceptable identity evidence to the registration authority before you create or issue their account credentials. Operationally, define what “acceptable evidence” means, train and authorize registrars, validate and record the evidence review, and retain auditable artifacts that show the check happened. ¹

Key takeaways:

• You need a registrar-run process that requires identity evidence before account issuance or credential binding. ¹
• Auditors will look for consistent, repeatable steps plus proof that the evidence was presented and reviewed, not just a policy statement. ¹
• Most failures come from “shadow” onboarding paths (contractors, break-glass admins, support) that bypass the registration authority.

IA-12(2) is a narrow requirement with a high operational impact: no identity evidence, no account. The control enhancement sits in the Identification and Authentication family and focuses on the moment of registration, the point where you bind a real person to a digital identity and issue credentials. It does not ask you to “do identity proofing” in the abstract. It asks you to make sure the registration authority requires evidence of identification and that people cannot bypass that checkpoint. ¹

For FedRAMP and other 800-53-based programs, this becomes a repeatable, auditable workflow: define acceptable evidence, designate who can act as registration authority (RA) or registrar, establish verification steps, and keep artifacts that let an assessor trace an account back to evidence that was presented at registration. If your onboarding spans HR, IT, and third parties, you also need controls that prevent exceptions from turning into informal standard practice.

This page translates the requirement into an implementation playbook a CCO, GRC lead, or compliance operator can put into production quickly, with concrete artifacts to collect and common audit traps to avoid.

Regulatory text

Requirement (verbatim): “Require evidence of individual identification be presented to the registration authority.” ¹

What the operator must do:
You must implement a registration process where the person requesting an account (employee, contractor, privileged admin, etc.) presents identity evidence to the function acting as the registration authority, and the RA uses that evidence as a prerequisite to registering the identity and issuing or binding credentials. The “presented” concept implies the RA sees the evidence through an approved channel and records that review occurred. ¹

Plain-English interpretation

• The control is a gate. Your system should not create accounts or issue credentials until the RA has confirmed identity evidence was presented.
• “Identity evidence” must be defined by you. The requirement does not list document types. Your policy and procedure must specify what counts, for which user populations, and what to do if evidence is missing or questionable.
• “Registration authority” must be real, not a mailbox. Auditors expect an assigned role (or team) with authority, training, and an accountable workflow.

Who it applies to (entity and operational context)

Entity scope: Cloud Service Providers and Federal Agencies operating under NIST SP 800-53 control baselines (including FedRAMP-aligned environments). ¹

Operational scope (where this shows up in practice):

• Workforce identity onboarding into enterprise IAM (SSO, directory, PAM)
• Privileged account creation (cloud console admins, database admins, security tooling admins)
• Contractor, temporary worker, and third-party user provisioning
• Break-glass and emergency access issuance (often the easiest bypass path)
• Service desk identity verification for account recovery and re-issuance events (even if your program treats this separately, assessors often probe it as “registration-like” activity)

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

1) Define the RA model and where the gate sits

1. Name the RA/registrar function (job role, team, or delegated set of trained individuals).
2. Map every account creation path that results in interactive access (HR-driven, ticket-driven, self-service, partner portal, emergency access).
3. Insert the RA check as a hard prerequisite in each path. If a path cannot enforce the check, treat it as a control gap and redesign it.

Practical tip: most organizations have multiple “mini RAs” (HR onboarding, IT service desk, PAM admins). Make that explicit rather than pretending there is one RA.

2) Define acceptable identity evidence and verification rules

Create a short standard that answers:

• What evidence types are acceptable for employees, contractors, and remote users.
• How evidence is presented (in-person inspection, secure video process, verified digital identity workflow, etc.).
• How the registrar verifies the evidence (what to compare, what to look for, when to reject).
• What to do on exceptions (expired document, name mismatch, urgent start date, inability to appear in person).

Keep it operational. Auditors will test whether staff follow it consistently.

3) Implement a registrar workflow with auditable checkpoints

Build a workflow (often in an ITSM tool) that includes:

1. Identity request intake (who requests, who approves).
2. Evidence presentation step with an attestation checkbox plus required fields (e.g., evidence type(s) presented, date/time, registrar name/ID).
3. Outcome and next action (approved, rejected, escalated).
4. Account issuance/binding step that cannot be completed until the evidence step is complete.

If you can’t technically block issuance, enforce the block through process and monitoring, then file a backlog item for technical enforcement. Expect this to be an audit discussion.

4) Control delegation, training, and separation of duties

• Authorize who can act as registrar. Maintain a list and review it as part of access governance.
• Train registrars on acceptable evidence, red flags, privacy handling, and how to record the check.
• Avoid self-registration for high-risk accounts. If the person can approve their own evidence check, you have an independence problem. Privileged accounts need the strictest RA process.

5) Handle special populations without bypassing the control

Common edge cases you should design explicitly:

• Contractors onboarded by a third party: require the sponsoring organization to route the individual through your RA process or provide evidence through an agreed method that your RA reviews.
• Remote hires: define a remote presentation method and ensure the RA documents it the same way as in-person.
• Emergency access: pre-register break-glass identities with evidence on file, or require an expedited RA verification path that still records presented evidence.

6) Monitor for bypass and clean up drift

Set up detective checks:

• New account monitoring: alert on accounts created outside the approved workflow.
• Privileged access monitoring: confirm privileged groups only contain identities that passed RA evidence checks.
• Periodic sampling: take a sample of new joiners and trace each to a completed identity evidence record.

7) Document it in your control narrative (what assessors read first)

Your narrative should tie together:

• Who the RA is
• What evidence is required
• How evidence is presented and recorded
• How the workflow prevents issuance before completion
• Where artifacts are stored and retention expectations

If you use Daydream to manage control narratives and evidence mapping, set up an “IA-12(2) evidence pack” that automatically pulls the standard, the registrar roster, and onboarding ticket samples into a single assessor-ready bundle.

Required evidence and artifacts to retain

Keep artifacts that prove the evidence was presented to and reviewed by the RA:

Policy and standards

• Identity proofing / registration procedure defining acceptable identity evidence
• RA/registrar role description and authority statement

Operational records

• Onboarding tickets or workflow records showing:
  • evidence presented (type/category)
  • registrar identity
  • date/time of check
  • approval/rejection outcome
• Exception records and approvals (with rationale and compensating steps)

Access governance

• List of authorized registrars and proof of access rights to perform RA actions
• Training completion records for registrars

Technical or monitoring artifacts

• Logs or reports showing account creation is routed through the approved workflow
• Alerts or findings for out-of-band account creation, plus remediation records

Privacy note: store only what you need to show the check occurred. If you retain copies of IDs, treat them as high-sensitivity data with strict access controls and retention rules.

Common exam/audit questions and hangups

Expect assessors to ask:

• “Who is the registration authority here, by name/role?”
• “Show me three recently created accounts and the identity evidence record for each.”
• “How do you prevent a service desk analyst from creating an account without the RA check?”
• “How do contractors and third-party users present identity evidence?”
• “What happens during account recovery or re-issuance? Do you require identity evidence again, or do you have a controlled alternative?”

Hangup pattern: teams can describe the process verbally but cannot produce consistent artifacts linking a real account to an RA evidence check.

Frequent implementation mistakes and how to avoid them

1. Mistake: Policy-only compliance. A policy says “we verify identity,” but onboarding tickets don’t capture evidence presentation.
   Avoid it: add required workflow fields and make account issuance contingent on completion.

2. Mistake: Privileged accounts bypass the RA. A cloud admin gets created by another admin “because it’s urgent.”
   Avoid it: force privileged provisioning through PAM workflows with RA evidence fields and independent approval.

3. Mistake: Third-party onboarding is outsourced and untraceable.
   Avoid it: require your RA to review evidence directly or require structured attestations plus a defined presentation method.

4. Mistake: Registrar list is informal. Anyone in IT “can do it.”
   Avoid it: maintain an authorized registrar roster and restrict workflow permissions accordingly.

5. Mistake: Evidence handling creates privacy risk. Teams store ID scans in shared drives.
   Avoid it: minimize collection, restrict storage, and document retention and access controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk-wise, IA-12(2) failures commonly lead to:

• accounts created for the wrong person (or a fictitious person),
• unauthorized access via weak onboarding controls,
• audit findings where the organization cannot prove the identity binding step occurred.

Treat this as both an access control requirement and an auditability requirement. You are building a chain of evidence from “real person” to “issued credentials.”

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Appoint the RA owner and define registrar roles.
• Inventory all account creation paths, including contractors and emergency access.
• Publish an “acceptable identity evidence” standard and registrar procedure.
• Update onboarding tickets/workflows to include mandatory identity evidence fields and registrar attestation.

Days 31–60 (enforce and collect artifacts)

• Restrict who can complete the RA step (role-based permissions).
• Train registrars and service desk on the procedure and documentation requirements.
• Run a sampling exercise: trace recent accounts to evidence records; remediate gaps.
• Define and start an exceptions register for edge cases.

Days 61–90 (monitor and harden)

• Add monitoring for out-of-band account creation and privileged group changes.
• Tighten emergency access so it cannot bypass RA evidence requirements.
• Tune artifact retention and access controls for evidence records.
• Build an assessor-ready evidence pack (policy + roster + ticket samples + monitoring outputs). Daydream can help keep this pack current by mapping artifacts to IA-12(2) and prompting owners when evidence goes stale.

Frequently Asked Questions

Do we have to keep copies of IDs to meet IA-12(2)?

IA-12(2) requires that evidence be presented to the registration authority, not that you retain copies. Keep enough record to prove the evidence was presented and reviewed, and handle any retained copies as sensitive data. ¹

Who counts as the “registration authority” in a modern IAM program?

It’s the role or function authorized to register identities and approve credential issuance. In practice it may be centralized (IAM team) or delegated (trained HR/IT registrars), but it must be explicit and auditable. ¹

How do we handle remote workers who can’t present documents in person?

Define an approved remote presentation method and require the registrar to document the presentation and review in the same workflow as in-person onboarding. The key is that the RA receives and evaluates the evidence before issuing credentials. ¹

Does this apply to contractors and other third-party users?

Yes if they receive individual accounts in your environment. You need an RA process that covers those populations and prevents sponsors or third parties from creating accounts without the evidence step. ¹

What’s the minimum auditors will accept as “proof” the evidence was presented?

A consistent registration record tied to the identity that shows the registrar, date/time, and what evidence was presented, plus a procedure that matches actual practice. Pure email approvals or verbal attestations without a controlled record often fail sampling.

How should we treat emergency or break-glass accounts?

Design them so they do not bypass identity evidence requirements. Pre-register the identities with evidence on file or require an expedited RA check that still records evidence presentation before activation.

Footnotes

1. NIST Special Publication 800-53 Revision 5