Customer due diligence is the process of verifying a customer’s identity and understanding the risk attached to that relationship. Wallet-based presentations can streamline it, but the institution remains accountable for deciding which attributes are trusted and how exceptions are handled.
Expanded Definition
Customer due diligence, often abbreviated as CDD, is the ongoing process of verifying identity, understanding expected activity, and assessing whether a relationship creates acceptable risk. In NHI-adjacent environments, the same logic applies when an organisation decides which presented attributes to trust, especially when wallets, federated identity, or delegated workflows are involved.
Definitions vary across vendors, but the core distinction is that CDD is not only about initial onboarding. It also includes monitoring for drift, validating exceptions, and deciding when additional evidence is needed before access is granted. That matters because identity proofing, entitlement decisions, and transaction risk are not identical problems. A strong CDD program can support NIST Cybersecurity Framework 2.0 functions such as Identify and Protect, but it does not replace internal policy judgment.
In practice, CDD becomes a control layer that translates policy into decisioning: who the customer is, what is normal for that customer, and what escalation path applies when the signal is incomplete. The most common misapplication is treating one-time identity verification as full due diligence, which occurs when onboarding teams assume a verified credential eliminates the need for ongoing risk review.
Examples and Use Cases
Implementing customer due diligence rigorously often introduces onboarding friction and review overhead, requiring organisations to weigh faster access against stronger assurance and better exception handling.
- A bank accepts a wallet-based presentation for identity attributes, then applies step-up checks when the requested service exceeds the customer’s normal activity profile.
- A SaaS provider uses CDD to verify whether a business customer is genuine before enabling API access, aligning the review with guidance in the NIST Cybersecurity Framework 2.0.
- An IAM team reviews exceptions for contractors using shared environments, ensuring the identity evidence matches the risk of the role rather than assuming all accounts need the same proofing depth.
- An organisation combines CDD with lifecycle controls described in the Ultimate Guide to NHIs when service accounts or agents trigger customer-facing actions that require human approval.
- A compliance team flags a customer whose attributes are valid but whose transaction pattern changes abruptly, prompting review instead of immediate denial.
These use cases show that CDD is as much about exception management as it is about verification. For deeper operational context, NHI governance patterns in the Ultimate Guide to NHIs help clarify how trust decisions should be recorded, repeated, and audited.
Why It Matters in NHI Security
Customer due diligence matters in NHI security because identity trust failures often begin with weak initial assumptions and then compound through automation. When presented attributes are not validated against the actual risk of the relationship, organisations can grant access to the wrong party, over-trust a delegated workflow, or miss abuse that appears legitimate at first glance.
NHI programs face the same governance pressure at machine scale. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which shows how quickly trust can exceed necessity when review processes are weak. That is why due diligence thinking belongs alongside lifecycle control, entitlement review, and incident response, not just onboarding. It also aligns with broader zero trust logic in NIST Cybersecurity Framework 2.0, where access decisions should be continuously informed by risk.
Organisations typically encounter the consequences only after fraud, account takeover, or a failed audit reveals that a trusted relationship was never properly validated, at which point customer due diligence becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL2 | Identity proofing assurance levels inform how much evidence CDD should require. |
| NIST CSF 2.0 | ID.AM | CDD supports asset and identity understanding by clarifying who is being trusted and why. |
| NIST Zero Trust (SP 800-207) | PEP/PDP concepts | CDD informs policy decisions by requiring continuous trust evaluation, not one-time approval. |
Match customer identity evidence to an appropriate assurance level before granting trust.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
