Identity Proofing | Address Confirmation

To meet the identity proofing | address confirmation requirement in NIST SP 800-53 Rev 5 IA-12(5), you must verify a user’s address of record by sending a registration code or proofing notice through an out-of-band channel and capturing evidence that delivery and confirmation occurred. Build this into registration, address changes, and re-proofing workflows, with auditable logs and procedures. ¹

Key takeaways:

• Use an out-of-band channel to deliver a code/notice to the address of record, then require confirmation before activating or changing identity attributes. ¹
• Operationalize the control at the “moments that matter”: initial registration, address updates, and account recovery. ¹
• Keep artifacts that prove the workflow ran as designed: configuration, samples, logs, and exception handling records. ¹

Address confirmation is a narrow requirement, but auditors treat it as a reliability test for your identity proofing program. If your system can’t demonstrate that the address of record was verified via an out-of-band channel, an assessor will question whether identity proofing events can be trusted, whether account recovery can be abused, and whether user identity attributes can be quietly altered.

This enhancement sits in the Identification and Authentication family and focuses on one thing: proving that the address on file belongs to the user by pushing a registration code or proofing notice through an out-of-band channel. “Out-of-band” is the key operational term. It means the confirmation signal must travel through a channel that is independent from the channel used to initiate the registration or change, so an attacker who controls one path does not automatically control the confirmation path.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalization is to (1) define what “address of record” means in your environment, (2) standardize which out-of-band methods are allowed, (3) hard-wire the workflow into your identity lifecycle, and (4) retain evidence that will survive an assessment. ¹

Regulatory text

Requirement (verbatim excerpt): “Require that a registration code or notice of proofing be delivered through an out-of-band channel to verify the users address of record.” ¹

Operator interpretation (what you must do):

• You must send either (a) a registration code or (b) a notice that proofing occurred to the user’s address of record using an out-of-band channel. ¹
• You must make the delivery meaningful: the workflow has to verify the address of record, not merely store it. In practice that means you either require the user to return the code (stronger) or you generate an auditable proofing notice event tied to the address, the identity, and the time. ¹

Plain-English requirement

Confirm that the address you have on file for a user is real and controlled by that user by sending a code or proofing notice through a separate channel than the one used to start the registration or change. Then record evidence that the confirmation step happened (or that you blocked/queued access until it happens). ¹

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating systems subject to NIST SP 800-53 controls (commonly through FedRAMP baselines). ¹

Operational contexts where auditors expect to see it implemented:

• New user registration / onboarding for workforce or customer identities that gain access to covered systems.
• Address of record creation or changes (email address, phone number, physical mailing address depending on your definition).
• Re-proofing or identity attribute refresh where the address is a relied-upon attribute.
• Account recovery flows when a “send code to address on file” step is part of the recovery.
  All of these are “high-risk identity moments” because they let someone bind an identity to an address, or re-bind it. ¹

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

Step 1: Define “address of record” for your system

Write a short definition that matches how the address is used:

• Email address of record (common for SaaS)
• Phone number of record (if SMS/voice is permitted in your program)
• Physical mailing address of record (for certain regulated workflows)

Document: Address of Record Standard with examples and which systems it covers. ¹

Step 2: Define “out-of-band” for your threat model and architecture

Out-of-band means the confirmation message travels through a channel that is not the same as the one used to initiate the action.

• If registration starts inside your web app, an email or SMS code can be considered out-of-band relative to the web session.
• If registration starts via email link, sending “confirmation” to the same email channel is not meaningfully out-of-band for many threat models. Decide this explicitly and document it.

Document: Out-of-Band Channel Policy listing allowed channels per identity type. ¹

Step 3: Choose the mechanism: registration code vs. notice of proofing

Create a decision rule your engineers can implement:

Option	What it proves	Typical use	Audit posture
Registration code delivered out-of-band	User can receive and return a code sent to the address of record	Account activation, address change, recovery	Stronger evidence because you can show delivery + successful confirmation
Notice of proofing delivered out-of-band	Proofing event notification reached the address	Risk alerting, detection, user awareness	Useful as an additional safeguard, but often needs pairing with another verification step

Set your standard: for example, require codes for address establishment/changes, and allow notices as a supplemental control for awareness and fraud detection. ¹

Step 4: Embed the workflow in identity lifecycle “gates”

Engineers need clear “block vs. allow” logic. Pick one and document it:

• Hard gate: do not activate the account (or do not accept the address change) until the out-of-band code is confirmed.
• Soft gate with restrictions: allow limited access until confirmation (only if you can defend this to assessors and your risk team).

Also define what happens on failure: retries, expiration, and escalation to manual review. Keep it consistent across systems. ¹

Step 5: Build secure delivery and confirmation handling

Minimum operational requirements most teams forget to specify:

• Ensure codes are single-use and tied to the correct identity, address, and transaction (registration vs. address change).
• Prevent “address swap” attacks by verifying the existing address of record before accepting a new one when feasible (for example, send a notice to the old address and require confirmation from the new address).
• Rate-limit code requests and confirmations to reduce brute force attempts.
• Log every stage: code generated, sent, delivered (if available), confirmed, expired, failed, locked.

You don’t need perfect deliverability telemetry, but you do need auditable evidence that your system attempted delivery and enforced confirmation rules. ¹

Step 6: Define exceptions and compensating controls

Write down the only acceptable exceptions (examples):

• User cannot access the out-of-band channel due to documented issue.
• Mission need requires temporary access pending verification.

For each exception type, require:

• Approval authority
• Time bounds (policy-defined)
• Compensating controls (manual ID check, supervisor approval, additional MFA)

Document: Exception Register entries with rationale and approvals. ¹

Step 7: Make it testable (continuous control evidence)

Turn the requirement into test cases:

• Create a test user, start registration, verify the out-of-band code is required, confirm activation only after confirmation.
• Attempt address change without confirmation and confirm the system blocks it.
• Pull logs that show the event chain and correlation IDs.

If you use Daydream to run control monitoring, map these test cases to recurring evidence pulls (configuration snapshots + sampled transactions + logs) so you can answer assessors quickly without rebuilding evidence by hand.

Required evidence and artifacts to retain

Assessors typically want “policy + procedure + proof it runs”:

1. Policy/standard

   • Address of Record Standard
   • Out-of-Band Channel Policy ¹

2. Procedure/runbook

   • Registration and address change workflows
   • Exception handling steps and approval matrix ¹

3. System evidence

   • Screenshots or configuration exports showing the gate (activation blocked until confirmed)
   • Message templates for the code/notice (email/SMS/letter), including security language
   • Logs showing: request initiated, code generated, message sent, confirmation success/failure, and final state
   • Sampled tickets or change records showing the control is maintained through releases ¹

4. Oversight evidence

   • Periodic access/identity workflow reviews
   • Exception register and management sign-off ¹

Common exam/audit questions and hangups

Expect these and prepare one-page answers with evidence pointers:

• “What is your address of record, and where is it defined?” ¹
• “Show me the out-of-band step for a new registration and an address change.” ¹
• “How do you prove the step is enforced, not optional?” Provide screenshots/config plus a log sample showing blocked state until confirmed. ¹
• “What happens if the user never receives the code?” Show retry logic, support workflow, and exception handling. ¹
• “How do you prevent an attacker from changing the address and confirming it themselves?” Show old-address notifications, step-up auth, and logging/alerts. ¹

Frequent implementation mistakes and how to avoid them

• Mistake: Treating ‘notice of proofing’ as enough for address verification. A notice increases visibility but may not prove the user controls the address. Prefer a code-based confirmation for address establishment/changes. ¹
• Mistake: Out-of-band in name only. If the initiating channel and confirmation channel collapse into the same compromised path, the control will not meet its intent. Define allowable out-of-band channels and document your rationale. ¹
• Mistake: No evidence chain. Teams log “verification succeeded” but cannot show the code send event, correlation ID, or transaction context. Require end-to-end event logging. ¹
• Mistake: Address changes bypass the workflow. Registration gets attention; profile edits become an unguarded door. Apply the same gate to address updates and recovery. ¹
• Mistake: Exceptions handled in chat. If it isn’t in a ticketing/workflow system with approvals, it will fail audit scrutiny. Use an exception register and link it to identity records. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this requirement. Practically, failures here raise the likelihood of account takeover, fraudulent identity binding, and undetected identity attribute changes. Those failures also weaken the credibility of downstream controls that rely on the address of record for MFA, recovery, or user notifications. ¹

Practical execution plan (30/60/90 days)

First 30 days (Immediate)

• Inventory where “address” exists (IdP, app profile, HR system) and pick the authoritative source.
• Publish definitions: address of record, allowed out-of-band channels, and which events require confirmation.
• Add an evidence checklist to your SDLC release template so engineering captures config + logs for the workflow. ¹

By 60 days (Near-term)

• Implement or standardize the out-of-band code/notice workflow for new registrations across in-scope apps.
• Extend the workflow to address changes and account recovery paths.
• Stand up centralized logging queries/dashboards that can produce an auditor-ready event trail on demand. ¹

By 90 days (Operationalize and audit-ready)

• Run a tabletop test: simulate registration, address change fraud attempt, and support exception handling. Capture evidence.
• Review exception register entries and tighten the approval matrix if exceptions are common.
• Automate recurring evidence pulls and sampling in Daydream so you can answer “show me” requests quickly and consistently. ¹

Frequently Asked Questions

Does “address of record” mean email, phone, or physical address?

The control does not constrain the address type; you must define what “address of record” means for your system and how it is used. Document the definition and apply the out-of-band workflow consistently to that address. ¹

Is sending a “proofing completed” email enough, or do I need a code?

The requirement allows a registration code or a notice of proofing, but a code-return flow provides clearer verification evidence. Many programs use notices as supplemental detection while requiring codes for activation and address changes. ¹

What counts as an out-of-band channel in practice?

Out-of-band means independent from the initiating channel. Define acceptable channels (email, SMS, postal mail, verified call-back) and document your rationale so assessors can see the separation you intended. ¹

Do we need to confirm the address again when a user changes it?

Yes, address changes are a primary abuse path. Apply the same out-of-band confirmation gate to updates and retain logs showing the change was blocked until confirmed. ¹

What evidence should we show an assessor during a FedRAMP assessment?

Bring the written standard/policy, the implemented workflow (screenshots or config exports), and a sampled log trail that ties a real transaction to message delivery and confirmation outcomes. Add your exception register and one or two exception examples if they exist. ¹

How do we handle users who can’t access the out-of-band channel?

Treat it as an exception with approvals and compensating controls, recorded in a ticketing system or exception register. Avoid informal overrides that leave no audit trail. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5