Topic starter
06/11/2026 6:40 pm
TL;DR: Strict obligations on customer account ownership, credential confidentiality, offboarding, data localization, and breach notification are placed on users of its IDV platform, according to Zumigo. The governance issue is not the service itself but the operational burden it pushes onto customers, especially where identity data, API tokens, and authorised-user access intersect.
Editorial analysis by NHI Mgmt Group, based on content published by Zumigo: “Zumigo IDV Builder Platform Terms of Service”.
Key questions
Q: Why do API tokens create risk in identity verification workflows?
A: API tokens create risk because they are bearer secrets that can be reused by anyone who obtains them, often without user authentication or step-up checks.
Practitioner guidance
- Define account ownership for every authorised user Assign a named business owner for each service account and require prompt offboarding when staff or contractors leave.
- Classify API tokens as governed credentials Store tokens in managed secret stores, restrict their use to approved applications, and rotate them on a fixed schedule or after any suspected exposure.
- Test localisation and retention controls before production use Verify that storage, backups, logs, and subprocessors remain within approved US-only boundaries and that deletion timing after termination is operationally testable.
Bottom line: Identity verification services create governance obligations around access, offboarding, and data handling that customer teams must own.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
Customer-controlled identity verification creates a lifecycle problem, not just an onboarding problem. Once a verification service is embedded into business operations, the governance burden shifts to the customer to own accounts, tokens, and offboarding. That is why identity verification should be treated as part of the broader service account security model, not as a one-time procurement step. The operational conclusion is simple: if access cannot be revoked cleanly, the service is already outside governance.
A few things that frame the scale:
- Gartner predicts that by 2026, 30% of enterprises will consider identity verification solutions unreliable in isolation because of AI-driven attacks.
A question worth separating out:
Q: Why do API tokens create risk in identity verification workflows?
A: API tokens create risk because they are bearer secrets that can be reused by anyone who obtains them, often without user authentication or step-up checks. In identity verification workflows they may allow record lookup, workflow submission, or data export, so teams should scope them narrowly, rotate them, and revoke unused tokens quickly.
👉 Read our full editorial: Identity verification terms expose governance gaps in customer access control