Skip to content

Vault & tokenisation

A token is a promise that the data is somewhere else

Tokenisation is often described as a security feature. It is more useful to think of it as a scoping decision: it determines how many of your systems a security assessor has to look at, and how many of them an attacker has a reason to visit.

Design phase — no vault is in operation

State of the work

Vault in operation
None. This describes intended design.
Open decision
Own isolated environment, or an already-validated third-party vault.
Why it is open
It is the decision that most affects assessment scope.
Being taken with
A qualified security assessor, rather than in advance of one.

What an application holds instead

A system integrating with Mirage Gateway is designed to receive enough to do its job and nothing more.

Intended to be available

  • A token referencing the stored payment method
  • Card brand
  • Last four digits
  • Expiry, where retention of it is permitted
  • Token status and lifecycle state
  • Payment status, amount and currency
  • Processor or acquirer reference

Not available, by design

  • The full card number
  • The security code — see below, this one is not negotiable
  • Any authentication data the card networks classify as sensitive
  • Unscoped detokenisation for convenience

The security code is not a card-on-file field

It is worth stating separately because it is the single most common design mistake in payment integrations.

A security code exists to prove that a card was present at one moment. Storing it so it can be replayed later defeats the only thing it does, and it sits in the category of sensitive authentication data that carries the strictest handling restrictions in the card industry standards.

Mirage Gateway is being designed with no persistent storage for it at all. That is a structural decision rather than a configuration option, because a field that exists eventually gets populated.

Token lifecycle

A token is not a permanent object. It is created under a consent, it is used under a scope, and it is destroyed when the reason for it ends.

  1. Capture

    Card data received into the isolated environment

  2. Vault

    Stored under hardware-backed key control

  3. Reference

    Token issued to the calling system

  4. Use

    Payment operations by reference only

  5. Expire

    Retention rule or deletion request

Diagram · Intended lifecycle. Not implemented.

Key management

Direction
Hardware-backed or equivalently hardened key control for vault encryption and key wrapping, rather than encryption keys held by the application that uses them.
Lifecycle
Documented generation, rotation, revocation, backup and recovery, with a cryptographic inventory that is maintained rather than reconstructed during an assessment.
Separation of duties
High-risk key operations require dual control. Break-glass access exists, is logged immutably, and is treated as an incident rather than a procedure.
What this is not
An encrypted database is not a key-management programme. The distinction matters because the first is a checkbox and the second is what actually protects the data when an application is compromised.

An open architecture decision, stated rather than hidden: whether the first version operates a Mirage-controlled isolated environment or consumes an already-validated third-party vault has not been settled. It is the decision that most affects assessment scope, and it is being taken with a qualified assessor rather than in advance of one.