IA-4(7): In-person Registration

IA-4(7) requires you to perform in-person identity registration for certain accounts so the person’s real-world identity is verified before credentials are issued or bound to an authenticator. To operationalize it quickly, define which roles and account types trigger in-person proofing, standardize the registration workflow, and retain auditable evidence that the check happened and who approved it. ¹

Key takeaways:

• Scope IA-4(7) to the highest-risk accounts (privileged, remote admin, sensitive data access) and document the trigger rules.
• Build a repeatable in-person registration procedure with separation of duties and a clear approval chain.
• Evidence wins assessments: keep proofing records, identity attributes verified, approver identity, and issuance logs mapped to each account.

The ia-4(7): in-person registration requirement exists for one reason: some accounts create enough operational and national-security-style risk that “remote-only” identity proofing is not an acceptable control on its own. NIST SP 800-53 treats identification and authentication controls as system-level requirements that must be implemented with consistency and assessed with evidence. IA-4(7) is a focused enhancement under the IA family that pushes you toward face-to-face identity verification during registration for defined scenarios. ¹

For a CCO or GRC lead, the fastest path to execution is to treat IA-4(7) as a policy-backed operating procedure with three outputs: (1) a scope statement that names which account types require in-person registration, (2) a standardized registration workflow that operations can follow without improvising, and (3) an evidence package that makes audits boring. This page gives you requirement-level guidance you can hand to IAM, security operations, HR/onboarding, and physical security to implement and sustain the control.

Regulatory text

Excerpt (as provided): “NIST SP 800-53 control IA-4.7.” ²
Control name: IA-4(7): In-person Registration ¹

What the operator must do

Because the provided excerpt is minimal, operationalization depends on aligning to the control’s intent in the NIST SP 800-53 Rev. 5 IA family: require in-person identity registration for the scoped population, and be able to prove it happened consistently. Your implementation must show:

• Defined scope (who/what triggers in-person registration).
• A documented registration process (how identity is checked in person, who performs it, what is verified).
• Credential issuance controls (credentials/authenticators are issued only after successful in-person registration).
• Auditable evidence that ties each registered identity to the approved account and authenticator binding. ¹

Plain-English interpretation (what IA-4(7) means in practice)

IA-4(7) means: for certain accounts, you do not create the digital identity “from a distance.” You require the person to appear in front of an authorized registrar (or equivalent) who validates identity artifacts and matches the person to the claimed identity, then records the result and authorizes credential issuance.

This is most commonly applied to:

• Privileged administrative access (domain admins, cloud root/admin roles)
• Accounts that can approve payments, modify security controls, or access regulated/high-impact datasets
• Access issued to third parties who will administer your environment (MSPs, integrators, incident response firms)
  Your scoping should be risk-based, but it must be explicit and consistently enforced. ³

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data adopting NIST SP 800-53 Rev. 5 as the control baseline. ³

Operational scope (where this shows up)

• New hires and transfers into sensitive roles
• Privileged access requests and emergency/break-glass access setup
• Third-party onboarding where the third party receives named credentials (not shared accounts)
• Re-registration after suspected identity compromise or major identity record changes (name/legal identity change, re-verification after HR data corrections)

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

Use this workflow as your minimum viable operating model. Keep it tight and enforceable.

Step 1: Define IA-4(7) trigger criteria (scope rules)

Create a short decision table that IAM can implement and auditors can test.

Example trigger table (customize):

Trigger	In-person required?	Owner
Privileged admin role in AD/Azure/AWS/GCP	Yes	IAM
Access to high-impact data repository	Yes	Data owner + IAM
Standard employee account	No (unless exception)	IAM
Third-party admin access (named account)	Yes	Vendor management + IAM

Deliverable: “IA-4(7) Applicability Statement” approved by Security and Compliance, referenced in your access control policy. ³

Step 2: Assign accountable roles and separation of duties

At minimum define:

• Registrar (verifies identity in person)
• Approver (authorizes the access request)
• Provisioner (creates the account / binds authenticator)
• Reviewer (periodic quality checks)

Common audit hangup: the same person both verifies identity and provisions privileged access without oversight. Build a two-person control for privileged roles.

Step 3: Standardize the in-person proofing procedure

Write a procedure that a trained operator can follow exactly. Include:

• Acceptable identity evidence (types of documents or authoritative sources) and what attributes you record
• Visual match requirement (registrar confirms the person matches the presented identity evidence)
• Handling of discrepancies (deny registration, escalate to HR/security, document outcome)
• Accessibility and remote-site handling (how you do this for distributed staff without weakening the control)

Keep the procedure short enough to run during onboarding without improvisation, and strict enough for privileged access.

Step 4: Control credential issuance and authenticator binding

Make issuance conditional:

• No account activation, password reset, MFA seed issuance, or PIV/CAC binding until in-person registration is marked complete in the system of record.
• If you must pre-stage accounts, keep them disabled until proofing completion.

Operational tip: implement a workflow gate in your IAM/ITSM tool so “Registrar Attestation” is a required field for scoped requests.

Step 5: Handle third-party identities explicitly

For third parties, treat “in-person” as a defined operational arrangement, not an assumption.

• Decide whether the in-person registrar can be your staff, an approved delegate at the third party, or an approved identity proofing service with physical presence.
• Require contractual language: cooperation with identity proofing, timely notification of role changes, and no credential sharing.

If the third party cannot meet in-person requirements for scoped access, document an exception and require compensating controls (tighter session monitoring, shorter access windows, stronger approvals). Keep exceptions rare and time-bound.

Step 6: Build the evidence trail and map it to the control

Auditors test IA-4(7) by sampling accounts and asking: “Show me the proofing record.” Your job is to make that retrieval fast.

Minimum: link each scoped account to a registration record in the ticketing or IAM system, with attachments or references to verified attributes and the registrar’s attestation. ³

Step 7: Monitor and re-check control operation

Run periodic checks:

• Identify privileged accounts created without a corresponding in-person registration record.
• Identify accounts where proofing was performed but access was never approved (process drift).
• Review exceptions and expirations.

If you use Daydream for GRC execution, treat IA-4(7) as a requirement with a named owner, a published procedure, and recurring evidence tasks so the control stays audit-ready without heroics.

Required evidence and artifacts to retain

Store evidence in a system that supports access controls and retention rules. Typical artifacts:

• IA-4(7) Applicability Statement (scope rules, account types, exceptions process)
• In-person registration procedure (step-by-step work instruction)
• Role definitions and training records for registrars
• Completed registration records per sampled identity, including:
  • Date/time of registration
  • Registrar name and attestation
  • Identity attributes verified (avoid storing excess sensitive document images unless required by policy; record what you checked)
  • Link to the access request and approval
• Credential issuance/binding logs (evidence issuance happened after proofing)
• Exception approvals with compensating controls and expiry
• Quality review reports (periodic sampling results, findings, remediation tickets)

Common exam/audit questions and hangups

Expect these questions and pre-answer them in your evidence package:

1. “Which accounts require in-person registration, and why?” Provide the trigger table and policy reference.
2. “Show three privileged accounts and the in-person proofing record.” Have a repeatable export/report.
3. “Who can act as a registrar? How are they trained?” Provide role assignment and training artifacts.
4. “Can the same person approve access and perform proofing?” If yes, explain compensating controls; better is separation.
5. “How do you handle distributed staff and third parties?” Provide the defined method and exception process.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “in-person” as a vague expectation.
   Fix: Write explicit steps, acceptable evidence, and failure handling. Operators should not guess.

2. Mistake: No system gate; proofing happens “out of band.”
   Fix: Make registrar attestation a required workflow field for scoped access, and block issuance until completion.

3. Mistake: Evidence is scattered (email threads, chat screenshots).
   Fix: Store proofing outcomes in a single system of record tied to the access request.

4. Mistake: Third-party access is exempt by default.
   Fix: Apply the same trigger rules. If exceptions exist, document compensating controls and an end date.

5. Mistake: Over-collection of identity data.
   Fix: Record the attributes verified and the method. Avoid retaining sensitive ID images unless your policy requires it and you can protect it.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for IA-4(7), so you should not plan around “penalty math.” Your risk is practical: weak registration controls increase the chance of privileged account takeover, fraudulent access grants, and inability to prove account provenance during incident response or assessment. IA-4(7) also tends to become an auditor focus area because it is testable with straightforward sampling: either the proofing record exists, or it does not. ³

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

First 30 days (Immediate stabilization)

• Name the control owner (IAM or Security) and the compliance owner (GRC).
• Publish the IA-4(7) Applicability Statement with trigger rules and an exceptions path.
• Draft the in-person registration SOP and registrar role definition.
• Identify where proofing evidence will live (ITSM/IAM ticket) and standardize the template.

By 60 days (Workflow enforcement)

• Implement workflow gates for scoped access (required registrar attestation; conditional provisioning).
• Train registrars and document training completion.
• Pilot with privileged access requests and at least one third-party onboarding flow.
• Start a lightweight QA review: sample completed registrations and verify evidence completeness.

By 90 days (Operational maturity)

• Expand scope coverage to all identified high-risk account types.
• Implement periodic drift detection (privileged accounts missing proofing evidence).
• Formalize exception reviews and require expiry dates and compensating controls.
• Package assessor-ready evidence: a control narrative, samples, logs, and a mapping of artifacts to IA-4(7). Daydream can track these recurring evidence tasks and keep ownership clear across IAM, HR, and Security.

Frequently Asked Questions

Does IA-4(7) mean every user must register in person?

No. IA-4(7) is typically scoped to defined high-risk populations. Your job is to document which account types trigger in-person registration and enforce it consistently. ³

Can we satisfy “in-person” with a video call?

Treat video as an exception unless your internal policy explicitly defines it as acceptable for IA-4(7) scope. If you allow it, document the method, controls against spoofing, and why it provides equivalent assurance, then be prepared to defend it during assessment. ³

What evidence do auditors actually want to see?

They want a sampleable trail: the access request, approval, proofing attestation by an authorized registrar, and issuance/binding logs showing credentials were issued after proofing. Keep it all linkable from the account record. ³

How should we handle third parties who need admin access but are offsite?

Define an approved registrar model (your staff, a delegated registrar under contract, or a controlled onsite process) and bake it into third-party onboarding. If you cannot meet in-person requirements, document an exception with compensating controls and an expiry. ³

Can HR onboarding count as in-person registration?

It can, if HR’s process meets your defined proofing steps and you can produce the evidence record tied to system account issuance. Many programs fail here because HR proofing evidence is not accessible or not linked to IAM records.

What’s the quickest way to get assessment-ready?

Start with privileged accounts, enforce workflow gates, and centralize evidence. A GRC system like Daydream helps by assigning an owner, storing the procedure, and scheduling recurring evidence pulls so you can answer sampling requests fast.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5