No. The control objective is related, but the risk tolerance is different. Workforce access often depends on operational continuity, while customer identity covers onboarding, recovery, and regulated transactions. Organisations should set assurance levels by use case, not force one verification threshold across all identity journeys.
Why the Same Verification Standard Rarely Fits Both Workforce and Customer Journeys
Verification is not one control objective with one universal threshold. Workforce access protects internal systems and productivity, while customer identity supports onboarding, recovery, and regulated transactions. The assurance level should match the decision being made: who is being admitted, what they can do, and how much friction the business can tolerate when the decision is wrong.
For workforce access, the dominant concern is usually reliable authentication with manageable interruption. For customer identity, the dominant concern is proving the right person at the right time, especially where account opening, recovery, or financial activity is involved. Those are related problems, but they are not identical control problems.
That difference is why organisations often separate authentication strength from identity proofing strength. Workforce journeys may accept simpler enrolment if the account is tightly governed later, while customer journeys may require stronger proofing at onboarding or step-up moments because the downstream fraud and recovery consequences are higher. IAM and IGA Basics is useful here because it separates access governance from the specific assurance used to establish the identity in the first place.
Where Assurance Levels Should Diverge
Use-case driven assurance means the verification standard should follow the transaction risk, not the organisation chart. A staff login to an internal productivity tool may justify one assurance pattern, while a customer attempting account recovery, payment change, or regulated onboarding may justify a different one.
Customer identity programmes often need to account for fraud tactics such as synthetic identity, account takeover, and recovery abuse. Workforce identity programmes more often prioritise secure enrolment, phishing-resistant authentication, and clean lifecycle management. The standard can therefore differ even when the underlying identity platform is the same. Customer IAM (CIAM) Guide helps frame the customer side, while Workforce Identity Security Guide addresses the employee side.
Verification standard also changes by journey stage. A first-time customer onboarding flow usually needs stronger identity proofing than a low-risk returning login. A workforce password reset, by contrast, may need stronger anti-recovery controls than the original sign-in because the reset path is a common takeover target. Identity Proofing and KYC Guide is the better fit when the question is about assurance at onboarding and recovery.
How to Set the Threshold Without Overstandardising
The right approach is to define assurance bands by journey, then map each band to the decision it protects. Workforce access bands should reflect internal privilege, device posture, and continuity needs. Customer bands should reflect onboarding risk, recovery risk, regulatory obligations, and the impact of mistaken acceptance or mistaken rejection.
That means organisations should avoid a single enterprise-wide “verification standard” that forces every user into the same proofing path. A strict standard that is appropriate for high-value customer onboarding may create unnecessary friction for low-risk workforce access. A lighter standard that is acceptable for everyday employee login may be inadequate for customer account recovery or financial authorization. OWASP ASVS is a useful external benchmark for thinking about authentication and access control strength by requirement rather than by slogan.
The practical test is whether the control still works when the journey is stressed. If the journey must recover accounts, support delegated access, or handle regulated transactions, the verification standard should be strong enough to resist abuse in those edge cases, not just the happy path. If a weaker process is chosen for continuity reasons, compensating controls should close the gap rather than pretending the journeys have equal risk.
Risk and Threat Considerations
Using one verification threshold everywhere creates two opposite failure modes: over-control on low-risk workforce access, and under-assurance on higher-risk customer journeys. In practice, that can either push users into unsafe workarounds or leave the organisation exposed to account takeover, recovery abuse, and fraudulent enrolment.
Failure mechanism: The same proofing rule is applied to different decisions, so the control no longer matches the trust required by the journey. Attackers then target the weakest point, usually account recovery, reset flows, or customer onboarding where friction and exception handling are highest.
Impact: The result can be reduced employee productivity, higher support load, failed onboarding, rejected legitimate users, or, more seriously, unauthorised access to customer accounts and regulated transactions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Separate assurance strength for different identity journeys depends on authentication requirements. |
| V8 — Authorization | Workforce and customer journeys differ by what each identity is allowed to do after verification. | |
| Recommendation — Use V6 to define stronger authentication where the journey needs higher assurance. Use V8 to align access decisions with the risk of each identity journey. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | The question is about matching verification strength to the identity decision being made. |
| Recommendation — Set assurance levels by use case rather than applying one threshold everywhere. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Customer identity journeys require stronger external-user authentication and proofing decisions. |
| IA-2 — Identification and Authentication (Organizational Users) | Workforce access is a separate authentication problem from customer identity proofing. | |
| Recommendation — Apply IA-8 where external-user identity assurance must be explicitly controlled. Apply IA-2 to workforce sign-in controls and related access assurance. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Different journeys need different access-control assurance and enforcement paths. |
| A.5.16 — Identity management | The question turns on how identities are established and governed across different populations. | |
| A.8.5 — Secure authentication | Verification standards ultimately determine the strength of authentication for each journey. | |
| Recommendation — Define access rules per journey and protect each with appropriate assurance. Segment identity management by workforce and customer use cases. Match authentication strength to the risk of the identity journey. | ||
Practitioner Guidance
What to prioritise: Set separate assurance profiles for workforce login, workforce recovery, customer onboarding, and customer recovery. Treat recovery as its own control path, because that is often where the real trust boundary breaks.
What to verify: Check that each journey has a stated purpose, an acceptable risk level, and an explicit fallback if the primary verification step fails. If the fallback is easier to abuse than the primary path, the standard is not really being enforced.
Decision rule: If the action can change money movement, legal ownership, or high-value account state, use the stronger customer-grade path. If the action only restores routine workforce access, optimise for continuity while keeping phishing-resistant authentication and lifecycle controls strong.
Practitioner takeaway: Do not ask whether the organisation should have “one standard”; ask which identity decision is being made, then set assurance to match the business and fraud impact of that specific decision.
Related resources from NHI Mgmt Group
- What breaks when identity verification is not tied to the same identity across web, workforce, and customer use cases?
- What breaks when organisations use workforce IAM for customer identity journeys?
- Should organisations use the same identity controls for internal agents and customer authentication?
- How should organisations use identity verification results in access decisions?