If your tokenisation and data masking platform is compromised: contain detokenisation, rotate keys and rebuild trust

A tokenisation and data masking platform is the one system that can turn every token in your estate back into a card number, account number or national identifier, so its compromise can undo the protection that let the rest of your systems hold tokens instead of data. The PCI Security Standards Council's Tokenization Guidelines put it plainly: compromise of the vault could result in the compromise of the entire tokenisation system, and compromised keys could expose all current and future tokens generated with them. This guide is a vendor-neutral response playbook for that scenario: what compromise looks like, triage questions, containment in priority order, deciding whether to re-key or re-tokenise, rebuild, evidence, notification and the masking side that is easy to forget. It is for data security engineers, PCI and privacy owners and incident responders, and assumes the controls in Securing the tokenisation and data masking platform itself. For the underlying techniques, see the Tokenisation and Data Masking Guide.

Key takeaways

• Stop detokenisation before anything else. Revoking the credentials and network paths that can redeem tokens for clear data limits the damage; most other steps can wait an hour, this one cannot.
• The answer depends on the token method. Random tokens in a vault expose only what was detokenised or read from the vault; format-preserving or other reversible cryptographic tokens become encrypted data if the key leaks.
• Detokenisation logs are your scoping record. Which identity redeemed which tokens, in what volume, is how you decide whether you have a breach of ten records or ten million.
• Re-keying and re-tokenising are different jobs. Re-encrypting the vault with new keys protects stored data; replacing tokens in every downstream system is a far larger project, needed only when tokens themselves can be reversed.
• Masked copies need checking too. An attacker who changed masking rules may have left real personal data in test, analytics or outsourced environments.

What a tokenisation platform compromise looks like

The PCI Tokenization Guidelines (Information Supplement, version 2.0, August 2011) describe four components: token generation, token mapping, the card data vault holding the clear values and their tokens, and cryptographic key management. Masking engines add a fifth: rule sets that decide how production data is altered before it is copied elsewhere. Each is a different compromise point.

Triggers and triage

Invoke this playbook for: a detokenisation volume spike from one caller or outside its normal hours; a new application identity, API key or role granted detokenise rights without a change record; an admin sign-in from an unknown device or network; audit logging disabled or a log gap; a vault export, backup restore or database dump outside a change; masking rules edited or a masking job run to a new target; key manager or HSM events showing key export or use by an unexpected identity; or fraud teams seeing card or account numbers used that only existed as tokens in your systems.

1. Preserve evidence first: export platform audit logs, detokenisation request logs, admin change history, key manager and HSM logs, and masking job history to storage the platform's administrators cannot alter.
2. Identify the token method per data set: random or sequence tokens in a vault, one-way tokens, or reversible cryptographic tokens such as format-preserving encryption. The guidelines warn that reversible encryption-based tokens are effectively encrypted values.
3. Establish what the compromised identity could do: detokenise, administer, read the vault store, reach keys, or edit masking rules. Each answer leads to a different branch below.
4. Size the exposure from logs: count distinct tokens redeemed by the identity in the window and compare with its normal baseline. If detokenisation logging was off or tampered with, treat everything the identity could reach as exposed.
5. Decide key exposure: if the attacker reached a data key or token generation key, or the identity that can unwrap it, treat every value protected by that key as exposed. NIST SP 800-57 Part 1 Rev. 5 states that a compromised key shall not be used to apply cryptographic protection to information, and that a suspect key shall be revoked.

Containment in priority order

1. Cut detokenisation for the compromised path: revoke the API keys, client certificates or service account credentials involved, and block their network routes to the platform. The guidelines list rejecting detokenisation requests from compromised systems as a recovery measure.
2. Restrict detokenisation to essential callers: move the platform to an allowlist of the callers the business cannot run without (payment capture, refunds, regulatory reporting), with tight rate limits. Tokenise-only traffic can usually continue.
3. Lock administration: limit console and management API access to named responders on clean admin devices, remove attacker-created roles and identities, and require dual control for any rights change. See the Break-Glass Account Guide for emergency access that does not depend on the platform's own identity provider.
4. Protect the keys: disable unwrap and export permissions at the key manager or HSM for every identity except the platform's own, and rotate the credentials the platform uses to reach it. See the Encryption Key Compromise Playbook for key scoping.
5. Freeze masking: pause scheduled masking and data refresh jobs until rule sets are verified against a known-good export.
6. Rotate every credential the platform holds: database accounts for the vault, backup credentials, directory bind accounts, and secrets used by its connectors. These are non-human identities with direct reach into clear data. See the Service Account Security Guide.

Keep the essential callers working. A tokenisation platform is often in the payment path, and an outage caused by blanket revocation can be worse for the business than a contained exposure. Agree in advance which callers are essential and how to run them on fresh credentials.

Re-key, re-tokenise or both

Re-tokenisation also breaks joins in analytics and reconciliation that rely on stable tokens, so plan a mapping period where old and new tokens coexist under strict access, then retire the old ones. Random vaulted tokens are the case where you can usually keep tokens in place: the guidelines require that clear values cannot be recovered from tokens alone, so with the vault and its key secured again, the tokens downstream remain safe.

Choosing the response depth

A smaller organisation using a hosted tokenisation service will mostly work through the provider: revoke its own API credentials, request the provider's detokenisation logs and key status, and confirm in writing what the provider rotated. A large estate running its own vault and HSMs needs the full branch structure above and a pre-built list of every system that stores tokens, ranked by whether it can detokenise.

Eradication and rebuild

• Close the entry point first: the leaked API key, the exposed management interface, the phished administrator or the vulnerable host. Rebuilding on the same weakness repeats the incident.
• Rebuild from clean sources: new hosts from known-good images, configuration from an export verified as pre-dating the window (NIST CSF 2.0 RC.RP-03), and a vault restored or re-encrypted under new keys.
• Re-enrol callers one by one: each application gets a new credential with the narrowest rights it needs (tokenise only, detokenise only, specific data sets), and is checked against its expected volume before full traffic resumes.
• Restore masking rules from a verified copy: then rescan non-production copies created in the window for clear values and destroy any that contain them.
• Retire old keys properly: NIST SP 800-57 Part 1 Rev. 5 moves a compromised key to the destroyed state once it is no longer needed to process protected data under controlled conditions.

Evidence and notification

• Preserve: detokenisation logs with caller, data set and count; admin audit trail; key manager and HSM logs; vault backup and restore history; masking job logs and rule diffs; host images where code execution is suspected.
• Payment cards: where card numbers may be exposed, follow your incident response plan under PCI DSS Requirement 12.10 and contact your acquirer and card brands as your agreements require. The guidelines treat all tokenisation components as part of the cardholder data environment.
• Personal data: under GDPR, tokenised data is pseudonymised personal data, not anonymous data (Recital 26). A controller notifies its supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, and tells individuals without undue delay where the breach is likely to result in a high risk to them (Recitals 85 and 86, Articles 33 and 34). A processor running tokenisation for a controller must tell the controller without undue delay.
• Customers of a tokenisation service: if you provide tokenisation to others, tell each affected customer which of their callers, data sets and keys were involved.

Whether exposure of tokens alone is notifiable depends on whether the attacker could reverse them. Record that analysis with the key evidence that supports it. See the Cyber Incident Reporting Requirements Map.

Detection and measurement

For at least 90 days after recovery (an NHI Mgmt Group recommendation), alert on: detokenisation volume per caller above its baseline; any new detokenise grant; admin logins outside named responders; logging configuration changes; key unwrap or export by any identity other than the platform; vault exports or backup restores; and masking rule edits.

• Time from declaration to compromised detokenisation path revoked.
• Share of callers with detokenise rights against those that only tokenise, target as low as the business allows.
• Detokenisation events attributed to a named caller and data set, target 100%.
• Vault values re-encrypted under new keys, and old keys destroyed, as a percentage.
• Non-production copies rescanned after masking rules were restored.

Common failure patterns

• Revoking the admin, not the application: the attacker's real foothold is often a detokenise credential in an application config, which keeps working after the admin account is disabled.
• Treating format-preserving tokens as safe: once the key is reached, every stored token is an encrypted value with a known key.
• Re-keying without destroying old key copies: backups of the HSM partition or key manager still hold the compromised key.
• Restoring configuration from a backup taken in the window: attacker-granted rights and raised rate limits come back with it.
• Forgetting masked copies: test and analytics environments refreshed while rules were weakened now hold real data with weaker access control.
• No baseline for detokenisation volume: without one, nobody can say whether redemption in the window was normal.

Framework mapping

Practitioner checklist

• Keep a register of every caller with detokenise rights, its data sets, owner and normal daily volume.
• Record the token method and key for each data set, so responders know immediately whether tokens are reversible.
• Stream detokenisation and admin logs to a SIEM the platform team cannot alter.
• Pre-agree the list of essential callers and how to reissue their credentials quickly.
• Keep a known-good export of rights, rate limits, logging settings and masking rules.
• Exercise a vault data key rotation and re-encryption, and time it.
• List every system that stores tokens, so a re-tokenisation can be planned without discovery work.
• Confirm with any hosted provider what logs and key evidence they will give you during an incident.

Standards and references

• PCI Security Standards Council: Information Supplement, PCI DSS Tokenization Guidelines
• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• NIST: SP 800-38G, Methods for Format-Preserving Encryption
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Data Manipulation: Stored Data Manipulation

Related NHI Mgmt Group resources: Securing the tokenisation and data masking platform itself · Tokenisation and data masking platform health check · If your secrets manager is compromised · PCI DSS Scoping and Network Segmentation Guide · Cryptographic Key Management Guide