How should security and IAM teams share responsibility for in-person identity checks?

Why This Matters for Security Teams

In-person identity checks are not just a front-desk process. They establish trust that can later affect account recovery, privileged enrolment, device issuance, badge access, and other identity-linked workflows. If security operations own only the physical step while IAM treats it as outside scope, the organisation creates a gap between who verified the person and what systems then trust that verification. That gap is where policy drift begins.

This is why governance must define the standard, not just the site procedure. The NIST Cybersecurity Framework 2.0 emphasises that identity controls need clear ownership, repeatable process, and evidence. NHIMG’s Ultimate Guide to NHIs makes the same operational point for non-human identity ecosystems: trust decisions only hold when the source of authority, the evidence captured, and the downstream use of that evidence are all defined up front. In practice, many security teams encounter identity fraud or enrolment abuse only after a help desk reset, badge request, or privilege grant has already converted a physical check into broader access.

How It Works in Practice

The cleanest model is a split between execution and control. Security operations, facilities, or local guards run the face-to-face workflow: inspect documents, compare likeness, validate presence, and record the outcome. IAM and governance teams define what “verified” means, which documents are acceptable, what attributes are authoritative, how exceptions are handled, and how long the verification remains valid before re-check is required.

That separation matters because a physical check is not the same as an identity proofing standard. A one-time desk-side review may be enough for badge pickup, but it may be insufficient for account recovery, admin role activation, or high-risk access requests. Current guidance suggests the trust level should be explicit and tied to the downstream action. If the physical verification is reused later, the system should know whether it was a basic presence check, a government-ID-backed proofing event, or a supervised re-enrolment.

• Security operations owns the workflow, evidence capture, and escalation path for suspicious presentations.
• IAM owns enrolment rules, proofing standards, attribute provenance, and when a check must be repeated.
• Governance owns auditability, approvals, retention, and the policy that defines acceptable verifier roles.
• Risk teams should define which workflows can consume the check and which require stronger assurance.

For teams building a broader identity control model, NHIMG’s 52 NHI Breaches Analysis shows how weak trust handling and poor governance translate into downstream compromise. The same pattern applies here: once an identity event is accepted as authoritative, every system that reuses it inherits the original control quality. These controls tend to break down when local sites invent their own verification rules because the organisation then loses consistent proof of what was checked, by whom, and for which access decision.

Common Variations and Edge Cases

Tighter identity proofing often increases friction, staffing cost, and user wait time, so organisations have to balance assurance against operational speed. That tradeoff becomes sharper for contractors, remote staff, and emergency access events, where a rigid in-person requirement may be impractical or unsafe.

There is no universal standard for this yet, but current guidance suggests using risk-based tiers rather than a single all-purpose check. A low-risk badge replacement can use a lighter workflow than a reset for privileged credentials. In high-assurance environments, the in-person check may need dual control, video evidence, or a second independent verifier. For distributed organisations, a central identity team should define whether satellite offices may perform checks locally or must route them to a controlled process.

One practical edge case is when facilities staff are asked to verify identity but are not trained to assess document fraud, exception handling, or escalation thresholds. Another is when a local check is accepted by downstream systems without an expiry, which effectively turns a one-time observation into long-lived trust. NHIMG’s Top 10 NHI Issues reinforces the broader lesson: identity controls fail when operational convenience outruns governance. The safest pattern is a shared model where security runs the room, IAM defines the rulebook, and audit can prove both happened.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?