What is the difference between customer due diligence and strong customer authentication here?

Why This Matters for Security Teams

customer due diligence and strong customer authentication solve different problems, even when they appear in the same digital journey. Due diligence establishes who the customer is, what risk attributes apply, and whether the relationship is acceptable. Strong authentication proves a specific session or transaction is being approved by the legitimate user at that moment. The distinction matters because control evidence, liability, and audit expectations are not interchangeable. NHI Mgmt Group’s guidance on identity governance shows why teams need to separate identity proofing from access proofing, especially when credentials, tokens, and other secrets move through automated workflows (Ultimate Guide to NHIs — What are Non-Human Identities). NIST CSF 2.0 also frames identity and access as distinct security outcomes, not a single control bucket (NIST Cybersecurity Framework 2.0).

For regulated teams, the mistake is assuming an EUDI Wallet, or any comparable digital identity mechanism, automatically satisfies both obligations. In practice, many security teams encounter gaps only after an investigation shows that onboarding evidence existed but transaction assurance did not, or vice versa.

How It Works in Practice

In operational terms, customer due diligence sits earlier in the lifecycle. It is about onboarding, risk classification, sanctions or fraud screening, and maintaining reliable customer records. Strong customer authentication sits at the point of use. It is about proving presence, possession, and authorised intent for a specific action. That means a single credential or wallet presentation may support both flows, but the relying party still has to decide what evidence is being captured and what policy requirement it satisfies.

Practitioners should separate the control questions:

• Does the control identify the person or organisation with enough confidence for onboarding and ongoing monitoring?
• Does it prove the same party is actively present for the transaction or access event?
• Does it bind the proof to a specific action, amount, channel, or risk condition?
• Can the evidence be audited later without confusing identity verification with session authorisation?

This is where implementation discipline matters. If the organisation uses wallet-based credentials, the wallet may reduce friction, but it does not erase the need for policy decisions about step-up checks, transaction binding, and liability allocation. The best practice is evolving, and current guidance suggests using separate assurance logic for onboarding and for transaction approval rather than treating them as equivalent. NHI Mgmt Group’s research on secrets and access sprawl is a useful reminder that weak identity boundaries create real operational exposure, especially when credentials are handled outside strong governance (Ultimate Guide to NHIs — What are Non-Human Identities). NIST’s identity and access guidance reinforces the same separation between verification, authentication, and authorisation (NIST Cybersecurity Framework 2.0).

These controls tend to break down when wallet claims, fraud controls, and downstream authorisation rules are all mapped to the same decision point, because the system can no longer show which assurance layer actually failed.

Common Variations and Edge Cases

Tighter assurance often increases user friction and integration overhead, so organisations have to balance fraud reduction against customer experience and legal precision. The hard part is that not every journey needs the same level of proof. A low-risk login may only require authentication, while a high-value transfer may require both updated due diligence signals and stronger transaction-level authentication.

There is no universal standard for this yet. Some regimes and implementations treat wallet presentation as a reusable trust anchor, while others require fresh, context-specific proof depending on the transaction type. That makes policy design more important than the technology brand. Teams should document which events require identity proof, which require transaction consent, and which require both. They should also make sure incident response can distinguish between an onboarding verification gap and a session-authentication failure, because those lead to different remediation paths and different liability arguments.

Where this gets messy is in delegated access, shared accounts, and high-volume automated journeys. If the same wallet or credential is reused across multiple services, assurance can degrade quickly unless step-up rules, revocation, and audit logging are kept separate. NIST CSF 2.0 is useful here because it encourages control mapping by outcome, not by marketing label (NIST Cybersecurity Framework 2.0).

Related resources from NHI Mgmt Group

• What is the difference between strong customer authentication and ordinary MFA?
• What is the difference between strong client authentication and least privilege?
• What is the difference between strong authentication and least privilege in cloud security?
• What is the difference between attestation-based identity and secret-based identity?