An identity verification and KYC platform decides who gets an account, so whoever can change its decision rules, overrule its results or call its APIs with stolen keys can create verified identities to order. The same platform stores passport and licence images, selfies, liveness video and biometric templates, which makes it one of the most sensitive data stores in the business. Most programmes focus on proofing strength (document checks, liveness, assurance levels) and much less on the platform's own admin roles, API credentials, webhooks, manual review console and data retention. This vendor-neutral guide covers that inside view for identity, fraud and security teams who run or integrate a verification platform, whether built in house or consumed as a service. For proofing itself see the Identity Proofing and KYC Guide; for choosing a platform see the Identity Verification Buyer's Guide.
Key takeaways
- Manual review is a privileged function. A reviewer who can override a failed check effectively issues an identity, so overrides need scope, second approval for high risk cases and an audit trail.
- Result integrity matters as much as proofing strength. If your application trusts a webhook or redirect without verifying it, an attacker can skip the platform entirely.
- API keys can mint sessions and read evidence. Keys that start verifications or fetch results and images need narrow scope, per-environment separation and rotation.
- Biometric and document data needs a retention clock. NIST SP 800-63A-4 requires a documented deletion process and default retention period for biometric data.
- Configuration changes weaken assurance silently. Turning off a liveness step, widening accepted document types or lowering a match threshold should be treated as a production change with approval.
What makes up a verification platform's attack surface
| Component | What it holds or does | Privileged identities involved | Primary hardening |
|---|---|---|---|
| Capture SDK or hosted flow | Collects document images, selfie and liveness media | Client tokens, publishable keys | Short-lived session tokens, injection attack detection |
| Verification API | Creates sessions, returns results, retrieves evidence | Server API keys, OAuth clients | Server side only, scoped per use, rotated |
| Result delivery | Webhooks and redirects that tell your application the outcome | Webhook signing secret | Signature verification, server side result fetch |
| Decision configuration | Workflows, accepted documents, thresholds, watchlist screening settings | Configuration administrators | Change approval, versioning, alerts |
| Manual review console | Human review of borderline cases, overrides | Reviewers, review leads | SSO with MFA, scoped queues, second approval for overrides |
| Evidence store | Images, video, templates, extracted attributes, consent records | Platform service accounts, support staff | Encryption, retention limits, access logging |
| Downstream integrations | Case management, CRM, sanctions screening, IdP | Integration service accounts | Least privilege, rotation, owner assigned |
Relevant techniques include ATT&CK T1078 Valid Accounts and T1098 Account Manipulation for console access, T1552 Unsecured Credentials for API keys in front end code or repositories, T1565.001 Stored Data Manipulation for tampered results or overrides and T1530 Data from Cloud Storage for exposed evidence stores. Attacks on proofing itself, such as injected camera feeds and deepfakes, are covered in the Deepfake-Resistant Identity Verification Guide.
Administrative roles and manual review
NIST SP 800-53 AC-5 (separation of duties) applies directly: nobody should be able to change verification rules, approve a failed applicant and edit the record of doing so.
| Role | Can do | Should not be able to do |
|---|---|---|
| Platform administrator | Users, SSO, API keys, webhooks, environments | Review or override cases |
| Workflow administrator | Propose changes to checks, documents and thresholds | Promote their own changes to production |
| Reviewer | Review assigned cases and record a decision with reasons | Override high risk failures alone, export evidence in bulk |
| Review lead | Second approval for overrides, quality sampling | Review their own team's overrides without sampling by another lead |
| Data protection or audit | Read logs, retention reports and access history | Change configuration or decisions |
- Admin authentication: dedicated admin accounts with phishing-resistant MFA (IA-2(1)) through SSO, and the platform's local owner account vaulted for break-glass.
- Override policy: NHI Mgmt Group recommends a second approver for any override of a failed document authenticity, liveness or face match check, and weekly sampling of approved manual reviews by someone outside the reviewing team.
- Reviewer collusion and coercion: outsourced or remote review teams are targets for bribery. Alert on reviewers with override rates well above their peers, and rotate case assignment rather than letting reviewers pick cases.
- Help desk and recovery paths: if account recovery reuses the verification platform, the same controls apply. See the Help Desk Identity Verification Policy Template.
API keys, webhooks and result integrity
- Keep secret keys on the server: start sessions from your back end and hand the client only a short-lived session token. Any key in a mobile app or browser bundle should be assumed public.
- Separate by environment and use: different keys for production and test, and for onboarding versus re-verification, so a leak in one place has limited reach. See the API Key Management Guide.
- Never trust the redirect: the user's browser returning to your site with "approved" proves nothing. Fetch the result server side, or verify the webhook signature and timestamp, and match the session ID to the applicant you started. See the Webhook Secrets Security Guide.
- Bind result to applicant: check that the verified name, date of birth and document data match the account being opened, so a verification completed for one person cannot be replayed for another.
- Evidence retrieval scope: most integrations need the decision, not the images. Use a separate, rarely used credential for evidence retrieval and log every call.
- Integration accounts: service accounts that push results into CRM, case management or the IdP are non-human identities under IA-9. See the Service Account Security Guide.
Biometric and document data
NIST SP 800-63A-4 (final, July 2025) sets requirements that are useful well beyond US federal use.
| SP 800-63A-4 requirement | Section | What it means for the platform |
|---|---|---|
| Policy for retention, protection and deletion of personal, sensitive and biometric data | 3.1 | Written retention schedule covering images, video, templates and backups |
| Explicit informed consent for biometrics, with consent records linked to the account | 3.11 | Consent captured in the flow and stored with an audit trail |
| Documented, publicly available deletion process and default retention period for biometric data | 3.11 | A deletion job you can evidence, and a published retention default |
| Protection of all personal information collected, including encryption at rest and authenticated protected channels | 3.5 | Encrypted evidence store, TLS everywhere, no evidence in logs |
| Controls consistent with the SP 800-53 moderate baseline regardless of IAL | 3.5 | Use 800-53 moderate as the floor for platform hardening |
| Risk assessment of third-party services | 3.5 | Assess every subprocessor that touches evidence |
| Presentation attack detection tests conformant to ISO/IEC 30107-3:2023, independently tested | 3.11 | Ask for test reports and re-check after algorithm changes |
| Controls for injected or manipulated digital media | 3.14 | Keep injection detection enabled; treat disabling it as a high risk change |
In the UK and EU, biometric data processed to uniquely identify someone is special category data under GDPR Article 9, so you need a lawful basis and an Article 9 condition, a data protection impact assessment is likely to be required, and processor terms should be strict. US state laws such as Illinois BIPA add consent and retention rules; see the Illinois BIPA and Biometric Privacy Guide. Confirm obligations with your privacy counsel for each market.
- Keep evidence out of logs and tickets: images and extracted document numbers should not be copied into application logs, support tickets or analytics tools.
- Support access: provider support staff access to your evidence should be time bound, approved by you and logged.
- Test data: use synthetic documents in test environments, never copies of real applicants' evidence.
Logging and monitoring
Forward platform logs to a SIEM the platform admins cannot alter (AU-9). Priority events:
- Workflow, threshold and accepted document changes, and any disabling of liveness or injection detection.
- Manual overrides, with reviewer, approver and reason, plus override rates per reviewer.
- API key creation, webhook endpoint changes and admin role grants.
- Evidence downloads and exports, and deletion job failures.
- Spikes in verifications from one device, IP range or document number, which may indicate automated abuse.
Hardening an existing platform: a phased approach
- Inventory (weeks 1 to 2): list admins, reviewers, API keys, webhook endpoints, integrations, workflows and where evidence is stored, including backups and subprocessors.
- Result integrity (weeks 2 to 4): move to server side result retrieval or verified webhooks, and bind results to the applicant. Test in a staging environment first and keep the old handler available for rollback until monitoring shows no failures.
- Roles and overrides (weeks 3 to 6): SSO with MFA, split workflow and review roles, second approval for high risk overrides.
- Credentials (weeks 4 to 8): separate keys per environment and use, move them to a secrets manager, rotate deployment era keys.
- Data (weeks 6 to 10): confirm retention and deletion are running and evidenced, purge evidence from logs and tickets, review support access.
- Monitoring (weeks 8 to 12): forward logs and build the alerts above.
Timings are NHI Mgmt Group recommendations.
Decision guidance
- Retain evidence or only results: keep images and video only as long as regulation or dispute handling requires; many teams can keep the decision, metadata and a hash, and delete the media sooner.
- Who reviews: in-house reviewers are easier to supervise; outsourced reviewers need contractual controls, scoped access and the same sampling.
- Small organisations: with no review team, configure the platform to decline rather than queue borderline cases, and route exceptions to a named senior person with logging.
Detection and measurement
- Override rate: overrides as a percentage of failed checks, overall and per reviewer.
- Second approval coverage: percentage of high risk overrides with an independent approver.
- Result integrity: percentage of integrations that verify webhooks or fetch results server side (target 100).
- Retention compliance: evidence older than the retention default (target zero).
- Key hygiene: days since rotation for each API key and webhook secret.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Roles, reviews and overrides | AC-2(7), AC-5, AC-6(5) | PR.AA-05 |
| Admin authentication | IA-2(1) | PR.AA-03 |
| API keys and integrations | IA-5, IA-9 | PR.AA-01 |
| Configuration change control | CM-3, CM-6 | PR.PS-01 |
| Evidence protection and retention | SC-28, SC-8, SI-12 | PR.DS-01, PR.DS-02 |
| Subprocessors | SA-9, SR-3 | GV.SC-05 |
| Logging and review | AU-6, AU-9, AU-12, AC-6(9) | PR.PS-04, DE.CM-03 |
Common failure patterns
- Trusting the client: the application accepts "verified" from a redirect parameter or unsigned callback.
- Secret key in the app: a server API key is shipped in a mobile app or web bundle.
- Single person overrides: reviewers approve failed liveness or document checks with no second look.
- Evidence everywhere: document images copied into tickets, logs and analytics, outside the retention process.
- Unreviewed workflow changes: a check is disabled to fix conversion and never turned back on.
Practitioner checklist
- Inventory admins, reviewers, keys, webhooks, workflows, integrations and evidence locations.
- Fetch results server side or verify webhook signatures, and bind results to the applicant.
- Keep secret keys on the server, separate them by environment and use, and rotate them.
- Require SSO with phishing-resistant MFA for admins and reviewers.
- Separate workflow changes from approval and require second approval for high risk overrides.
- Document and evidence retention and deletion for images, video and templates.
- Keep evidence out of logs and tickets and control provider support access.
- Forward logs to a SIEM and alert on configuration changes, overrides and exports.
Standards and references
- NIST: SP 800-63A-4 Identity Proofing and Enrollment
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- OWASP: API Security Top 10 2023
- MITRE ATT&CK: Stored Data Manipulation
- ICO: Biometric data guidance, biometric recognition
Related NHI Mgmt Group resources: Identity Proofing and KYC Guide · NIST SP 800-63A-4 Identity Proofing (IAL) Guide · Biometric Liveness and Presentation Attack Detection Guide · Identity Verification RFP Template