A Customer Identification Program is the set of procedures a financial firm uses to collect and verify customer identity information at onboarding. It is an assurance and governance control, not just a data collection step, because every later monitoring and compliance decision depends on the quality of that identity record.
Expanded Definition
A Customer Identification Program, or CIP, is the procedural control a financial firm uses to establish a customer’s identity before account opening. In practice, it sits between onboarding and risk governance: the firm collects identifying attributes, verifies them against reliable sources, and records the outcome so downstream monitoring, sanctions screening, and fraud controls can trust the underlying identity record.
In NHI and agentic environments, CIP matters because the same identity-quality problem appears when organisations onboard machine actors, delegated workflows, or third-party automation. The control logic is similar even when the subject is not a person: prove who or what is being admitted, preserve evidence, and keep the record usable across later access and anomaly decisions. NIST’s NIST Cybersecurity Framework 2.0 frames this as governance and identity assurance rather than a one-time intake form.
Definitions vary across vendors when CIP is applied to digital channels, synthetic identities, or non-human onboarding, so organisations should treat the term as an assurance process, not a document checklist. The most common misapplication is treating CIP as a mere data-entry step, which occurs when onboarding teams collect fields without verifying source quality or retaining auditable evidence.
Examples and Use Cases
Implementing CIP rigorously often introduces onboarding friction, requiring organisations to weigh faster customer activation against stronger identity confidence and regulatory defensibility.
- A retail bank asks for government-issued identification, verifies it against trusted data sources, and stores the verification result for audit and case review.
- A digital lender adds document validation and fraud screening before account activation so later transaction monitoring is anchored to a validated identity record.
- A fintech onboarding flow flags mismatched names, disposable contact details, or unverifiable addresses for manual review before approval.
- A platform that issues API credentials to partners applies CIP-like checks to the business customer and the authorised operator before provisioning access.
- Security teams use lessons from incidents such as the JetBrains GitHub plugin token exposure to reinforce why identity proofing and post-onboarding control evidence must be reliable, then map that discipline to the onboarding workflow in line with NIST Cybersecurity Framework 2.0.
For NHI governance, the analogous use case is onboarding service accounts, API clients, or agents with explicit ownership, approval, and traceability before secrets or permissions are issued.
Why It Matters in NHI Security
CIP is important because weak identity proofing at the front door becomes an access-control and monitoring problem everywhere else. If the identity record is wrong, later decisions about anomaly detection, privileged access, sanctions exposure, or offboarding can be built on false assumptions. In NHI environments, that risk is amplified because service accounts, API keys, and automated agents often inherit trust quickly and are harder to inspect later.
The governance lesson is not abstract. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs. That makes identity assurance at onboarding directly relevant to preventing downstream credential abuse and misattribution. A strong CIP discipline also supports least-privilege rollout, segregation of duties, and later revocation when an account, customer, or automation path changes.
Organisations typically encounter the consequences only after fraudulent enrolment, account takeover, or a compromised automation path forces a backfill investigation, at which point CIP 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.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | CIP supports governance by establishing trusted identity records for onboarding decisions. |
| NIST SP 800-63 | IAL2 | Identity proofing and verification levels define how strongly a customer must be validated. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Poor onboarding and weak identity assurance are root causes of NHI trust failures. |
Make identity proofing part of governance so every onboarding decision rests on verified records.
Related resources from NHI Mgmt Group
- Why does device identification matter for customer identity programmes?
- What does a mature secrets governance program need to cover?
- What is the difference between a bug bounty program and a vulnerability disclosure policy?
- What is the difference between strong customer authentication and ordinary MFA?
