Identity Verification Platform Compromise Playbook

An identity verification and KYC platform decides who is allowed to open an account and holds the identity documents, selfies and biometric data that prove it, so its compromise is two incidents at once: a breach of highly sensitive personal data and a loss of trust in every verification decision it made. An attacker who reaches the platform can read stored evidence, approve fraudulent applicants through review queues or forged results, or lower the checks so synthetic and stolen identities pass. This guide is a vendor-neutral response playbook for organisations that run or rely on such a platform: how compromise shows up, triage, containment in priority order, deciding which verifications to distrust, re-verification, rebuild, evidence and notification. It is for fraud, identity and incident response teams, and assumes the controls in Securing the Identity Verification and KYC Platform Itself.

Key takeaways

Treat it as a data breach and an integrity incident. Stored documents and biometrics drive notification; manipulated decisions drive fraud loss. Run both workstreams from day one.
Stop new decisions being trusted first. Hold automatic approvals and route new applications to a separate review path until result integrity is confirmed.
Define the window of distrust. Every verification approved between the earliest attacker activity and containment needs a risk-ranked review, not just the ones you can see were altered.
Do not delete evidence to reduce exposure. KYC record retention duties still apply; protect the records and the audit trail instead.
Tell relying parties quickly. NIST SP 800-63A-4 requires a credential service provider to communicate suspected and confirmed fraud events to relying parties.

What a verification platform compromise looks like

Compromise point	What the attacker can do	ATT&CK v20
Relying application API keys or client credentials	Read past verification results and evidence; create sessions; query applicant data	T1078, T1213
Result webhook signing secret or callback endpoint	Send forged "approved" results that the relying application accepts	T1565.002
Admin console or rules configuration	Lower match thresholds, disable liveness, document or database checks, add allowlists, change data retention	T1078, T1556
Manual review queue or reviewer accounts (including outsourced reviewers)	Override rejections and approve fraudulent applicants; bulk-download cases	T1078, T1199
Evidence store (document images, selfies, video, biometric templates)	Bulk exfiltration of identity documents and biometric data for reuse in fraud	T1530
Decision records	Alter stored outcomes or audit records to hide approvals	T1565.001
Capture channel (SDK, web capture page)	Inject pre-recorded or synthetic media at scale while presentation and injection checks are weakened	T1585

The integrity side is what makes this different from most data breaches. Accounts opened through manipulated decisions keep working after the platform is clean, and they may be used for money mule activity, credit fraud or access to services that rely on your verification.

Triggers and triage

Invoke this playbook for: a jump in approval rate or a fall in rejection rate without a product change; approvals with no matching platform session, or webhook results with signatures from an unknown key; threshold, check or allowlist changes without a change record; a reviewer overriding many rejections or downloading cases in bulk; evidence store reads at unusual volume; a provider reporting an incident; or fraud teams finding a cluster of new accounts with shared devices, addresses or document templates that all passed verification.

Preserve evidence: export platform audit logs, configuration history, reviewer actions, API and webhook logs, evidence store access logs and decision records to storage the platform administrators cannot change.
Classify the compromise: confidentiality (evidence read or taken), integrity (decisions forged, overridden or checks weakened), or both.
Set the window: earliest attacker activity to containment. If logs do not show the start, use the earliest configuration change or credential issue date you cannot explain.
Measure the data exposure: which applicants' documents, selfies, biometric templates and extracted attributes were reachable, and which were actually read.
List decisions in the window: every approval, override and result delivered, with the check results behind each.

Containment in priority order

Hold trust in new results: switch relying applications to pending review for new verifications, or enforce a server-side fetch of each result from the platform instead of accepting pushed webhook results.
Revoke and reissue integration secrets: API keys, client certificates and webhook signing secrets for every relying application. Treat them as non-human identities with owners. See the Webhook Secrets Security Guide and API Key Management Guide.
Lock administration and review: limit admin access to named responders, suspend reviewer accounts involved, remove attacker-created users and roles, and require a second reviewer for every override.
Restore check configuration: revert thresholds, enabled checks and allowlists to a known-good export and freeze further changes.
Protect the evidence store: rotate storage credentials and encryption key access, and block bulk export paths. Do not delete records to shrink exposure.
Freeze high-risk downstream actions for accounts verified in the window: outbound payments, credit drawdowns, limit increases and data changes such as new contact details.

If you rely on a provider, most of steps 3 to 5 sit with them. Ask for their containment actions, the identities involved, and logs scoped to your tenant, in writing.

When the provider is the one compromised

Many organisations do not run the platform: they call a provider's API and receive results. When the provider announces an incident, your exposure depends on your integration, not only on what the provider says about its own systems.

Question to the provider	Why it matters
Which of our tenant's credentials, webhook secrets and reviewer accounts were reachable?	Decides which secrets you reissue and whether your results may have been forged
Was evidence (images, video, templates) for our applicants accessed, and for which date range?	Drives your own notification analysis as controller
Were any configuration, threshold or decision records changed for our tenant?	Decides the integrity workstream and the window of distrust
Which logs scoped to our tenant can you deliver, and when?	Your regulator expects your assessment, not a copy of the provider's statement
What did you rotate, rebuild and verify, and how was it tested?	Basis for deciding when to resume automated decisions

Do not wait for complete answers before acting on your side: reissue your integration secrets, move to server-side result fetches and start ranking accounts in the window while the provider investigates. The 72-hour clock under GDPR runs from when you, as controller, become aware, which may be the day the provider tells you. See the Identity Verification Buyer's Guide for the incident terms worth putting in the contract next time.

Deciding which verifications to distrust

Decision in the window	Treatment	Priority
Approved with no matching platform session or with an unverifiable result signature	Treat as unverified: restrict the account and re-verify through a clean path	Immediate
Approved by a manual override from a suspect reviewer	Restrict and re-verify; check linked accounts	Immediate
Approved while thresholds or checks were weakened	Re-run stored evidence through restored checks where possible; re-verify those that fail	First week
Approved normally, platform integrity uncertain	Risk-score using fraud signals (device, address, velocity, first transactions); re-verify the high-risk tail	Within 30 days (NHI Mgmt Group recommendation)
Rejected in the window	Sample for wrongful rejection if rules were changed; offer redress	Normal

Re-verification should use a path the attacker could not influence: a fresh session with restored configuration, a different evidence route, or attended verification for the highest-risk cases. NIST SP 800-63A-4 asks credential service providers to document the conditions that require reverification and to give subscribers redress mechanisms that are easy to find and use, including recovery of a compromised account. Plan the customer message before you send re-verification requests: legitimate customers will be asked to repeat a process at the moment phishers may be imitating it. See the Identity Proofing and KYC Guide.

Choosing the response depth

Decision	Option A	Option B	Choose B when
New applications during response	Continue with restored checks and second review of approvals	Pause automated onboarding	Result integrity cannot yet be confirmed or the entry point is not closed
Accounts in the window	Re-verify risk-ranked subset	Re-verify all	The window start is unknown or decisions were altered without trace
Platform	Clean in place	Rebuild, or move relying applications to a new tenant or provider	Code ran on platform hosts, or the provider cannot show tenant-scoped evidence
Biometric templates	Keep, with new storage keys	Delete and re-enrol	Templates were exfiltrated and your design allows re-enrolment without them

A small business using a hosted verification service will mostly act through integration secrets, the relying application and its customer accounts. A bank or large platform running reviewers and its own evidence store needs the full set, plus coordination with its financial crime team on suspicious activity reporting for accounts opened fraudulently.

Eradication and rebuild

Close the entry point: the leaked API key, phished admin, insecure reviewer workstation or unvalidated webhook endpoint.
Restore configuration from a verified export pre-dating the window (NIST CSF 2.0 RC.RP-03) and diff every rule, threshold and allowlist.
Enforce result integrity: relying applications verify webhook signatures with the new secret and confirm each result by fetching it from the platform before acting.
Re-establish reviewer controls: per-reviewer limits on overrides and case downloads, second review for overrides, and NIST SP 800-63A-4 insider threat controls to detect collusion by representatives.
Re-test capture defences: confirm presentation attack detection and injection controls are back on. NIST SP 800-63A-4 requires remote biometric collection to use PAD tested to ISO/IEC 30107-3:2023, and controls that detect virtual cameras and emulators. See the Biometric Liveness and Presentation Attack Detection Guide.

Evidence and notification

Preserve: audit logs, configuration history, reviewer actions, API and webhook logs, evidence store access logs, decision records and the list of accounts in the window.
Keep KYC records: for US banks, the Customer Identification Program rule (31 CFR 1020.220) requires identifying information to be kept for five years after the account is closed and verification records for five years after they are made. Other regimes have similar duties.
Personal data regulators: biometric data processed to identify a person is special category data under GDPR Article 9. Notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, and tell individuals without undue delay when the breach is likely to result in a high risk (Articles 33 and 34; Recitals 85 and 86). A processor tells the controller without undue delay. US state biometric laws may also apply; see the Biometric Privacy Laws Map.
Relying parties: under NIST SP 800-63A-4 a credential service provider shall communicate suspected and confirmed fraud events to relying parties, and should share them in near real time.
Financial crime: accounts found to be opened fraudulently go through your suspicious activity reporting process; CIP procedures must already say when to close an account and when to file a report.

Affected individuals whose documents were taken face identity fraud risk long after the incident. Give them concrete steps. See the Credit Freezes and Fraud Alerts Guide and the Cyber Incident Reporting Requirements Map.

Detection and measurement

For at least 90 days after recovery (an NHI Mgmt Group recommendation), alert on: approval rate changes outside expected bands; approvals without a matching session; unsigned or wrongly signed webhooks; configuration and allowlist changes; override volume per reviewer; evidence store reads per identity; and clusters of new accounts sharing devices, addresses or document features.

Time from declaration to all integration secrets reissued.
Accounts in the window reviewed, re-verified or closed, as a percentage.
Approvals confirmed by server-side result fetch, target 100%.
Fraud losses on accounts opened in the window, tracked against the pre-incident cohort.
Overrides with second review, target 100%.

Common failure patterns

Running it only as a data breach: notification gets done, but fraudulent accounts opened in the window keep operating.
Trusting pushed results: relying applications that accept a webhook without fetching the result let a stolen signing secret approve anyone.
Re-verifying through the same weakened path: restored thresholds must be confirmed before re-verification starts.
Deleting evidence to cut exposure: breaks record retention duties and removes what investigators need.
Ignoring outsourced reviewers: review vendors' accounts and devices are part of the platform's attack surface.
Re-verification messages that look like phishing: no prior warning to customers, generic links, and no way to confirm the request is genuine.

Framework mapping

Framework	Reference	Where it applies
NIST SP 800-63A-4	3.2 fraud management, 3.6 redress, 3.11 biometrics, 3.14 injection	Fraud communication to relying parties, reverification and redress, PAD and injection controls
NIST CSF 2.0	RS.AN-03, RS.MI-01, RS.MI-02, RS.CO-02, RC.RP-03	Scoping, containment, eradication, notification, verified restoration
NIST SP 800-53 Rev. 5	IA-12, IR-4, IR-6, AC-6, AU-9, SC-28	Identity proofing, incident handling and reporting, least privilege, audit protection, data at rest
31 CFR 1020.220	(a)(2), (a)(3)	Verification procedures, KYC record retention
MITRE ATT&CK v20	T1078, T1199, T1213, T1530, T1556, T1565.001, T1565.002, T1585	Credential and reviewer abuse, evidence theft, check tampering, forged results, fraudulent accounts

Practitioner checklist

Register every integration secret and webhook signing secret with an owner and a reissue procedure.
Make relying applications fetch and check each result server-side before acting on it.
Keep a known-good export of thresholds, enabled checks and allowlists.
Baseline approval rates and reviewer override volumes so anomalies are visible.
Pre-write the re-verification customer message and a clean re-verification path.
Agree with any provider what tenant-scoped logs and evidence they will give you during an incident.
Map which records retention rules apply before any deletion decision.
Exercise the playbook with fraud, privacy and financial crime teams together.

If your identity verification and KYC platform is compromised: contain access, re-verify accounts and notify