Topic starter
11/08/2026 3:10 pm
TL;DR: Identity verification should be embedded in account claim, onboarding, MFA, passwordless enrollment, helpdesk validation, and recovery workflows rather than treated as a separate project, according to Fischer Identity. That model matters because identity assurance only holds when proofing, binding, and lifecycle governance operate as one controlled process.
Editorial analysis by NHI Mgmt Group, based on content published by Fischer Identity: “Identity Verification Should Be Built Into the Identity Lifecycle.”.
Key questions
Q: How should organisations integrate workforce identity verification into IAM processes?
A: They should connect verification outcomes directly to provisioning, access escalation, and re-verification rules so the control changes access rather than just collecting evidence.
Q: Why do passwordless and continuous assurance still need strong identity proofing?
A: Because removing passwords does not remove the need to know who is enrolling and who is recovering access.
Q: What breaks when identity verification is managed as a separate project?
A: Proofing evidence, credential state, and access decisions become disconnected.
Practitioner guidance
- Integrate verification into account claim workflows Use authoritative source systems to trigger proofing before credentials are issued, and bind the verified identity to the onboarding record so later access decisions inherit the same assurance state.
- Align MFA and passwordless enrollment to proofing Require the person to complete identity verification before registering mobile authenticators, hardware keys, or passwordless methods, so the authenticator is bound to a verified subject.
- Unify helpdesk recovery with lifecycle assurance Make password reset, caller validation, and account recovery depend on the same identity record and assurance level used for initial proofing, rather than on ad hoc support procedures.
Bottom line: Identity verification is most defensible when it is part of the governed identity lifecycle rather than a separate onboarding add-on.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/08/2026 3:25 pm
Identity verification should be governed as a lifecycle control, not a standalone event. The article correctly rejects the idea that proofing can be bolted on after account creation, because identity trust only remains coherent when the same authoritative record drives claim, credential issuance, recovery, and ongoing access decisions. For IAM teams, this means the verification workflow is part of governance design, not an isolated intake step.
A question worth separating out:
Q: How should teams decide when to re-verify a user during recovery or support?
A: They should re-verify whenever the workflow can restore access, reset a credential, or change a high-risk identity attribute, because those are assurance-sensitive events. The decision should be based on the same identity record and risk posture used at initial proofing, not on whichever support channel the user happened to reach. That keeps recovery from becoming an uncontrolled exception path.
👉 Read our full editorial: Identity verification belongs inside the identity lifecycle