Identity Proofing

Identity proofing is the front door control for access management: it answers “who is this person?” before you answer “what can they do?” Under FedRAMP Moderate, IA-12 is the requirement-level expectation that users who need accounts for logical access are identity proofed at an appropriate identity assurance level (IAL) aligned to applicable standards and guidelines. ¹

For a CCO or GRC lead, the fastest path to operationalizing IA-12 is to treat it as an onboarding gating control: no proofing, no account. That sounds simple until you hit real-world complexity: contractors onboarding through a third party, admins with elevated access, service desk exceptions, remote hires without in-person verification, and legacy accounts with unclear provenance.

This page turns IA-12 into implementable requirements: who is in scope, how to select and document IAL, what to do step-by-step, what evidence to retain, and the exam questions that typically break teams. It’s written to help you set a defensible, auditable standard quickly, then scale it without creating helpdesk bottlenecks.

Regulatory text

Requirement (excerpt): “Identity proof users that require accounts for logical access to systems based on appropriate identity assurance level requirements as specified in applicable standards and guidelines.” ¹

Operator interpretation (what you must do):

1. Decide what “appropriate” means for your environment by establishing an identity assurance level (IAL) standard for different account types and risk tiers (for example: standard users vs. privileged admins).
2. Perform identity proofing before account issuance for any user who will receive a logical access account.
3. Retain proofing evidence and traceability so an assessor can sample accounts and confirm that proofing occurred, met the stated IAL, and preceded access enablement. ¹

Plain-English interpretation (identity proofing requirement)

Identity proofing is verifying that a real person is who they claim to be, with rigor matched to risk, before you create credentials that can access systems. IA-12 is not satisfied by “the manager said it’s them,” an email from HR, or a self-attested web form. You need a defined proofing method, applied consistently, with evidence you can produce on demand. ¹

Who it applies to (entity and operational context)

Entities in scope:

• Cloud Service Providers (CSPs) operating a FedRAMP Moderate-authorized service or pursuing authorization.
• Federal Agencies operating or consuming systems aligned to the FedRAMP Moderate baseline. ¹

Operationally, the requirement applies to:

• Employees, contractors, and other workforce members who receive accounts for logical access.
• Privileged users (admins, cloud console administrators, IAM administrators).
• Third-party users (for example, MSP staff or implementation partners) if they receive accounts into your environment.
• Remote access accounts and accounts that can reach sensitive data paths.
• Exceptions and break-glass users: IA-12 still applies; the process may be different, but it must be defined.

Common scoping pitfall: teams only proof “new hires,” while leaving contractors, third-party support users, and privileged admins to ad hoc methods. IA-12 is account-driven: if they require an account for logical access, they are in scope. ¹

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

Below is a practical implementation sequence you can assign to IAM + GRC + HR/People Ops + Service Desk.

Step 1: Create an IAL decision standard (documented)

Define:

• IAL tiers you will use (even if you don’t name them formally, you need a consistent categorization).
• Which systems and account types map to which IAL (standard workforce account, privileged admin, third-party support, customer admin for certain deployment models).
• What proofing methods satisfy each IAL (examples: government ID verification with liveness checks; in-person verification; trusted digital identity provider).
• When re-proofing is required (examples: name change, suspicious identity signals, conversion from standard to privileged).

Deliverable: a short “Identity Proofing Standard” that an assessor can read and a helpdesk can execute. Tie it explicitly to IA-12. ¹

Step 2: Build identity proofing into your joiner workflow as a hard gate

Design the workflow so the account cannot be created or activated until proofing is complete. Practical patterns:

• HR-driven onboarding: HR initiates; proofing is completed; IAM provisions.
• Contractor onboarding: sponsor initiates; third party provides required identity artifacts; proofing completed; IAM provisions.
• Third-party support access: require proofing for named individuals, not shared identities, before issuing accounts.

Controls to include:

• Unique identifier assignment (person record).
• Separation of duties: the approver of access is not the same as the person who performs proofing, unless you have a documented compensating control.

Step 3: Implement proofing methods that are actually auditable

Pick proofing methods you can evidence. Auditors will test:

• Completeness: every sampled account has proofing.
• Timing: proofing occurred before initial access.
• Consistency: proofing met the declared IAL for that account type.
• Integrity: evidence cannot be easily altered without trace.

If you use a proofing vendor, ensure you can export logs/results and retain them per your retention policy.

Step 4: Handle special cases without “one-off” chaos

Create mini-procedures for:

• Remote hires without in-person verification
• Urgent access requests (controlled, time-bound, documented, and followed by proofing if you allow any emergency path)
• Legacy accounts (see Step 5)
• Name changes and identity record merges
• Break-glass accounts (ideally no standing human identity ambiguity; use named individuals, strong controls, and documented custody)

Step 5: Remediate legacy accounts (prove or disable)

Assessors regularly sample older accounts. If you cannot prove identity proofing occurred, you need a policy-backed remediation path:

• Re-proof the user to the required IAL; or
• Disable the account; or
• Convert to a service account with proper ownership controls if it was misclassified.

Step 6: Make it testable (continuous control monitoring mindset)

Operational checks you can run:

• Accounts created in the last period with no proofing record.
• Privileged accounts where proofing evidence is missing or does not meet the required IAL.
• Third-party accounts with expired sponsorship or missing identity evidence.

Where Daydream fits naturally: teams often fail IA-12 because evidence is scattered across HR tickets, identity provider logs, and email attachments. Daydream can act as the control “system of record” for identity proofing by standardizing the workflow, collecting artifacts, and producing an assessor-ready trail per account, without relying on tribal knowledge.

Required evidence and artifacts to retain

Retain artifacts that show what you required, what you did, and that you did it before access:

Policy/standard artifacts

• Identity Proofing Standard (IAL mapping by account type/system risk)
• Identity lifecycle procedures (joiner/mover/leaver) showing proofing gate
• Exception process (who can approve, conditions, documentation required)

Per-user evidence (sampleable)

• Proofing result record (pass/fail, date/time, method, reviewer/verifier identity)
• Identity attributes captured (as permitted by your policy)
• Linkage from proofing record to:
  • account request ticket
  • account creation event
  • access approval record (especially for privileged access)

System evidence

• Workflow configuration screenshots or exports showing proofing as a required step
• IAM/IdP logs showing account creation timestamps
• Access request system logs showing approval chain

Retention note: use your established retention schedule; auditors will care that it’s consistent and supports sampling across the account lifecycle.

Common exam/audit questions and hangups

Expect questions like:

• “Show me your identity proofing policy and how you determine the appropriate IAL.” ¹
• “Pick five newly created accounts and show proofing evidence for each, including timestamps.”
• “How do you identity proof contractors and third-party users?”
• “How do you prevent the service desk from bypassing proofing for urgent requests?”
• “Show that proofing occurs before privileged access is granted.”
• “What do you do for legacy accounts created before this control was implemented?”

Hangups that create findings:

• Proofing evidence exists but is not linked to the account (no traceability).
• Proofing is performed, but after access is granted (timing failure).
• Privileged accounts follow a different path with weaker proofing “because they’re trusted.”

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating authentication strength as identity proofing. MFA proves control of a factor, not real-world identity.
   Fix: require proofing before issuing the identity that will enroll MFA.

2. Mistake: Shared accounts for third parties. You cannot proof “SharedAdmin.”
   Fix: require named individual accounts; map each to proofing evidence and sponsorship.

3. Mistake: Evidence stored in email or chat. It won’t survive staff turnover or audit sampling.
   Fix: centralize proofing records in a ticketing system, GRC workflow, or dedicated repository with access controls and an audit trail.

4. Mistake: No defined IAL mapping. “Appropriate” becomes subjective, and assessors will push.
   Fix: document the mapping, get it approved, and apply it uniformly. ¹

5. Mistake: Legacy accounts ignored. Auditors sample them.
   Fix: run an inventory, triage high-risk accounts first (privileged and third-party), then systematically re-proof or deprovision.

Execution plan (30/60/90-day)

First 30 days (stabilize and define)

• Publish an Identity Proofing Standard with an IAL decision matrix aligned to your environment. ¹
• Inventory account populations: workforce, privileged, third-party.
• Implement a gating rule for new privileged accounts first (highest risk).
• Define the evidence bundle you will retain per account and where it will live.

Days 31–60 (implement and backfill)

• Expand gating to all new accounts that provide logical access.
• Build repeatable procedures for contractors and third-party users.
• Start legacy remediation for privileged and third-party accounts.
• Run internal sampling: pick accounts and verify traceability end-to-end.

Days 61–90 (operationalize and audit-proof)

• Complete workflow automation where possible (ticket templates, mandatory fields, API-driven provisioning holds).
• Formalize exception handling and periodic QA checks.
• Prepare an assessor packet: policy, procedures, sample evidence, and system configuration excerpts.
• If evidence is fragmented, consolidate via a workflow system (Daydream or equivalent) so you can produce per-account proofing trails quickly.

Frequently Asked Questions

Does IA-12 apply to service accounts and system-to-system identities?

IA-12 is written for “users that require accounts for logical access.” If a non-human identity is misclassified as a “user,” you will struggle to show identity proofing. Define a clear distinction between human user accounts (proofed) and non-human accounts (separately governed). ¹

Can HR verification count as identity proofing?

It can, but only if you have a defined standard for what HR must verify, how it maps to your IAL decision, and you retain evidence. An informal “HR confirmed” note usually fails traceability and consistency tests.

What about remote contractors provided by a third party?

Require proofing for named individuals before issuing accounts, and require a sponsor. You can accept proofing performed by a third party only if your standard defines what you will accept and you can retain sufficient evidence to support audit sampling.

Do we need to re-proof users periodically?

IA-12 focuses on proofing users who require accounts. Re-proofing is a risk decision: define triggers such as privilege elevation, suspicious identity indicators, or identity attribute changes, and document them in your standard. ¹

How do we prove “proofing happened before access” to an assessor?

Keep timestamps for proofing completion and account activation/creation, and ensure they’re linkable to the same person record. Auditors typically accept ticket and system log correlation when it is consistent and tamper-resistant.

What’s the minimum evidence we should store per user?

Store the method used, the outcome, the date/time, who performed the verification (or which provider did), and a reference that links to the user’s account request and provisioning record. The goal is reproducible sampling, not a one-off screenshot.

Footnotes

1. NIST Special Publication 800-53 Revision 5