Security

Designed in, not retrofitted

Payment security added after launch is a remediation project. Added before, it is an architecture. This page describes the intended security model for Mirage Gateway — and it is a design, not an attestation of controls in operation.

Pre-certification — design phase

State of the work

Independently assessed: No. Nothing on this page has been reviewed by an assessor.
In production: Nothing. Controls described here are design, not evidence.
Next gate: A QSA scoping engagement, before the environment is frozen.
Reporting a vulnerability: [email protected]

What this page is

The intended security architecture, published while it is being built rather than after. Describing a control here is a statement of design, not evidence that it is operating — when that evidence exists it will be offered as evidence. Programme states are on the compliance roadmap.

Trust domains

Separation is the first control. The design starts by deciding what must never be able to reach what.

Public API and edge
Merchant control plane
Payment orchestration
The isolated payment environment and vault
Key management boundary
Security and audit logging
Analytics and warehousing, containing no card data
Support and operator tooling, seeing masked data only

Security domains

Scope minimisation

The security perimeter is kept as small as it can be made. Every system brought inside it has to be segmented, monitored, patched, assessed and defended — so the cheapest control available is not adding it in the first place.

Tokenisation

Applications hold references. The account data sits in one isolated environment, which is what keeps a compromise of an ordinary service from being a compromise of payment data.

Least privilege

Short-lived service identities, default-deny between trust domains, strong authentication with multi-factor for privileged access, and no standing production access held by convenience.

Encryption

In transit and at rest, with strong service-to-service authentication for sensitive internal paths rather than trust inherited from being inside a network.

Secrets and keys

Centralised secret management, never in source control. Hardware-backed key protection for vault operations, documented lifecycle, rotation, and dual control on high-risk key operations.

Auditability

Immutable security and payment event logs carrying correlation identifiers, built so that an investigator can reconstruct what happened without asking an engineer to remember.

Monitoring

Authentication, privileged access, tokenisation, payment actions, configuration changes, key operations and failed access, alerted on rather than merely retained. Logs must never become an accidental store of card data.

Secure development

Architecture and security review gates, code review, dependency and secret scanning, static analysis, container and infrastructure-as-code scanning, and approvals on production change.

Vulnerability management

Asset inventory, risk-ranked intake, remediation service levels, retesting after remediation, and evidence retained rather than reconstructed.

Penetration testing

Independent qualified testing at defined intervals and after material changes to the payment environment.

Incident response

A documented plan with defined severities, a payment-security escalation path, exercises, and a post-incident review standard.

Continuity and recovery

Documented continuity and disaster recovery with recovery objectives by service tier, off-host backups, a key-recovery plan, and restore tests that are actually run.

Assumptions the design refuses to make

Each of these is a common shortcut, and each one produces a security posture that fails its first real assessment.

Tokenisation removes scope: It reduces scope. The service performing the tokenisation is squarely inside the perimeter, and so is everything that can affect its security.
The cloud provider is compliant: A provider's validation covers the provider's responsibilities. It says nothing about how a workload running on it is built, configured or operated.
An encrypted database is key management: Encryption with keys held by the application that reads the data protects against a stolen disk and very little else.
Self-assessment will be sufficient: Whether a service provider may self-assess depends on the service, the volumes and what the accepting entity requires. It is confirmed, not assumed.

Reporting a vulnerability

Security reports go to [email protected].

See also the compliance roadmap for the state of each formal programme.