Tokenisation and masking move sensitive data into one platform, so that platform's vault, keys, detokenisation API and unmask policies become the single place an attacker needs to reach. Once applications hold only tokens or masked values, the risk concentrates on whoever can call detokenise, hold the format-preserving encryption key, change a masking policy or read the vault database. Most of those callers are service accounts and workload identities. This guide is for data security, payments security and platform teams that run a tokenisation or data masking platform, whether vaulted, vaultless, self-hosted or a service. It covers admin roles and dual control, application identities, keys, policy changes, test data jobs, logging, backup and lifecycle. It is vendor-neutral: confirm setting names in your vendor's documentation. For how tokenisation and masking work and how to choose between them, see the Tokenisation and Data Masking Guide.
Key takeaways
- Detokenise is the privileged action. Treat every identity that can detokenise or unmask as having access to the original data, and scope it by data type, return format and volume.
- Separate administrators from users of the data. People who manage the platform, its keys and its policies should not be the people or services that consume clear data.
- Keys need dual control. Keep tokenisation and format-preserving encryption keys in an HSM or key management service, with split knowledge and dual control for key ceremonies.
- Policy changes are data access changes. Changing a masking rule or a detokenise permission exposes data as surely as a database grant; route them through approval and log them.
- The vault is the data. A token vault and its backups hold the sensitive values; protect them as the most sensitive store you have.
What makes up the platform's attack surface
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Admin console and API | Policies, token formats, users, application identities, key references | Grants detokenise rights, weakens masking, creates new clients | SSO with phishing-resistant MFA, least-privilege roles, dual control for sensitive changes |
| Token vault (vaulted designs) | Mapping of tokens to original values | Bulk theft of the original data | Encryption at rest with keys outside the database, restricted database access, segmentation |
| Tokenisation and FPE keys | Keys that protect the vault or generate tokens (vaultless designs) | Reverses every token offline | HSM or key management service, split knowledge, dual control, usage logging |
| Detokenise and unmask API clients | Service credentials that return clear or partially masked values | Scripted bulk detokenisation through a legitimate client | Per-application identity, field and format scope, rate limits, anomaly alerts |
| Masking policies | Rules deciding who sees full, partial or masked values | Turns masking off for a role or all users | Policy as code with review; alert on policy changes |
| Test data masking jobs | Connections to production sources and test targets | Unmasked production data copied to test | Dedicated job identities, verification that output is masked |
| Backups and replicas | Copies of the vault and configuration | Offline theft of the vault | Encrypted backups, separate access, tested restores |
Admin roles, dual control and console access
- Separate duties: define at least platform administrator (system settings, users), policy owner (token formats, masking and detokenise policies), key custodian (key ceremonies and rotation), auditor (read logs) and application owner (requests access for their service). No single person should hold platform administrator and key custodian together.
- Dual control: require two people for key generation, import, export and destruction, and for changes that grant detokenise or unmask rights to new identities (our recommendation for policy changes). The aim is that no single person can expose clear data or keys alone.
- Administrators do not see clear data: platform administrators manage the system; they should not hold detokenise rights themselves. Grant clear-data access only to identities with a recorded business need.
- Authentication: enforce SSO with phishing-resistant MFA and keep one documented break-glass account. The CISA and FBI Secure by Demand guide suggests buyers ask whether SSO is available at no additional cost and whether MFA is enabled by default. See the Break-Glass Account Guide.
- Admin devices: administer from privileged access workstations. See the Privileged Access Workstations Guide.
Application identities that tokenise and detokenise
| Identity | Needs | Avoid | Pattern |
|---|---|---|---|
| Capture service (tokenise only) | Submit values and receive tokens | Detokenise rights "in case they are needed" | Tokenise-only client per application |
| Payment or fulfilment service (detokenise) | Clear values for one data type at the moment of use | Access to every token format; bulk detokenise endpoints | Per-service identity scoped to field and format, rate limited, certificate or federated credential |
| Support and analytics users | Partially masked values, such as last four digits | Full unmask by default | Masked by default; time-bound, approved and logged unmask |
| Batch and reporting jobs | Defined volumes in defined windows | Interactive logon; shared credentials with online services | Dedicated job identity with volume caps and schedule restrictions |
| Test data masking job | Read production source, write masked output | Write access to production; clear output | Dedicated identity; output checked for unmasked values |
- Strong credentials: prefer mutual TLS client certificates or workload identity federation for API clients over static API keys. Where keys remain, store them in a secrets manager with an owner and expiry, and rotate them (our recommendation: at least every 90 days). See the Service Account Security Guide.
- Minimise return format: return partial or masked values unless the caller genuinely needs the full value.
- Volume limits: set per-identity rate and volume limits for detokenisation, so a stolen client credential cannot drain the vault quietly.
- PCI DSS: systems that can detokenise card data stay in scope for PCI DSS. See the PCI DSS Scoping and Network Segmentation Guide and the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6).
Keys and cryptography
- Where keys live: keep vault encryption keys and format-preserving encryption keys in an HSM or a key management service, never in application configuration or the vault database. NIST SP 800-57 Part 1 Rev. 5 gives general guidance on protecting and managing keying material. See the HSM Deployment and Operations Guide and the Cryptographic Key Management Guide.
- Separate keys by purpose: use different keys for different data types and environments, so a test key never protects production data.
- Format-preserving encryption: NIST SP 800-38G specifies FF1 and FF3. The second public draft of SP 800-38G Rev. 1 (February 2025) no longer specifies FF3, citing a weakness in its tweak schedule that also affected FF3-1, and increases the FF1 domain size. Ask your vendor which method and domain sizes the platform uses, and confirm the current value in the vendor's docs.
- Rotation and re-tokenisation: plan how keys are rotated and whether existing tokens must be re-issued. For vaultless designs, rotating a key can change every token, so test the process before you need it.
- Key recovery: document escrow and recovery with dual control. See the Recovery of Cryptographic Keys and Secrets Guide.
Hardening, availability and backup
- Segment the platform: place the tokenisation service and vault in a dedicated network segment, reachable only by approved clients and administrators.
- Restrict database access: no person should query the vault database directly in normal operation; direct access goes through break-glass with dual control.
- Availability: if the platform is unavailable, payments or services that need detokenisation stop. Design for high availability and document what each application does when the service is down; never fall back to storing clear data.
- Backups: encrypt vault backups with keys held separately from the backup store, restrict who can restore them, and test restores. A backup of the vault is a copy of the data.
- Updates: apply vendor security updates promptly and subscribe to the vendor's security advisories.
Logging and monitoring
- Log every detokenise and unmask: record identity, data type, volume, return format and time. Do not log the clear values themselves; the OWASP Logging Cheat Sheet lists payment card data, keys and sensitive personal data among data that should not be recorded directly.
- Log administration: export sign-ins, role and policy changes, new clients, key operations and configuration changes to your SIEM, outside the platform administrators' control.
- Alert on misuse: detokenisation volume above baseline, a new identity detokenising, requests outside expected hours, unmask requests in bulk, and any masking policy change.
See the PCI DSS Requirement 10 Guide and the Secrets Access Logging and Detection guide.
Lifecycle and decommissioning
- Onboard an application: record its identity, data types, return formats, volume limits and owner; approve before credentials are issued.
- Review: review detokenise and unmask rights every quarter (our recommendation) and remove unused clients.
- Retire an application: revoke its credentials and remove its policies.
- Migrate or leave: plan re-tokenisation or detokenisation of stored tokens under dual control, export audit logs you must keep, destroy keys through a recorded ceremony, and obtain written confirmation that vault data and backups are deleted.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Admin roles and dual control | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Application identities | IA-5, AC-6 | PR.AA-01 | T1552 Unsecured Credentials |
| Keys | SC-12 | PR.DS-01 | T1552 Unsecured Credentials |
| Vault and backups | SC-28, CP-9 | PR.DS-01, PR.DS-11 | T1565.001 Stored Data Manipulation |
| Audit log protection | AU-6, AU-9, AC-6(9) | PR.PS-04 | T1685 Disable or Modify Tools |
Common failure patterns
- Everyone can detokenise: one shared client credential with full detokenise rights is used by every application.
- Keys beside the vault: the vault encryption key sits in a configuration file on the same host as the database.
- Masking turned off for convenience: a support role was given full unmask during an incident and kept it.
- Clear data in test: a masking job failed silently and copied production values into a test database.
- Unprotected backups: vault backups are readable by the general backup administrators.
Practitioner checklist
- Separate platform administrator, policy owner, key custodian, auditor and application owner roles.
- Enforce dual control for key operations and for granting detokenise or unmask rights.
- Give each application its own identity, scoped by data type, return format and volume.
- Keep keys in an HSM or key management service, separated by purpose and environment.
- Confirm the FPE method and domain sizes your platform uses against current NIST guidance.
- Segment the platform and block routine direct access to the vault database.
- Encrypt and restrict vault backups, and test restores.
- Log every detokenise and unmask without clear values, and alert on unusual volume or new callers.
- Review rights quarterly and keep a documented key destruction and exit plan.
Standards and references
- NIST: SP 800-38G Methods for Format-Preserving Encryption
- NIST: SP 800-38G Rev. 1 (second public draft)
- NIST: SP 800-57 Part 1 Rev. 5 Recommendation for Key Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NCSC: Secure system administration
- OWASP: Logging Cheat Sheet
- CISA and FBI: Secure by Demand Guide
Related NHI Mgmt Group resources: Tokenisation and Data Masking Guide · Data Masking and Tokenisation Buyer's Guide · Cryptographic Key Management Guide · Securing the PAM Vault Itself