Security is the product
Interlink Wallet holds signing credentials and customer data on behalf of other organisations. We designed every layer on the assumption that something, somewhere, will eventually go wrong, and made sure the damage stays contained.
Defence in depth, by design
These controls are running in production today.
Isolation enforced by the database
Every tenant table uses forced row-level security in PostgreSQL. Each request runs inside one organisation's context, and a query without that context is refused rather than returning everything. Cross-organisation references are blocked by the schema itself.
Sealed signing keys
Pass signing keys are envelope-encrypted with a per-organisation key, bound to their owner so they cannot be moved between records. Only the signing component's own database role can read them, it unseals a key only for the moment it signs, then wipes it from memory. Moving signing onto a separate isolated host is on our roadmap.
Least privilege everywhere
Each service connects with its own database role. The web service can register devices but cannot read secrets; the API can store credentials but never read them back; the contact form can add an enquiry and nothing else.
Tamper-evident audit log
Privileged actions are written to an append-only log where every entry is chained to the one before by a cryptographic hash. Editing or deleting history is blocked, and any tampering is detectable.
Secrets never stored in clear
API keys are stored only as Argon2id hashes and shown once. Pass authentication tokens are stored as hashes. Download links are signed and expire.
Hardened web surface
HTTPS only with HSTS, a strict content security policy with no inline code and no third-party scripts, rate limits on every endpoint that accepts data, and uniform responses that reveal nothing to attackers.
Minimal data, clear roles
A pass shows only what the holder needs to see. We never put bank details, card numbers or documents on a pass, and we never use your customers' data for our own purposes.
- You are the controller of your customers' data; we process it on your instructions under a data processing agreement.
- Apple and Google operate the Wallet apps on each device as independent controllers of what happens on the phone.
- Retention agreed with you. We keep pass data only for as long as your agreement requires.
- Encrypted nightly backups, verified automatically after every run.
| Data | Why we hold it |
|---|---|
| Pass content | The values you choose to show, such as a balance or appointment time |
| Your reference | Your own identifier for each holder, so updates reach the right pass |
| Device tokens | Issued by Apple or Google so we can tell a device to refresh |
| Signing credentials | Sealed; used only to sign passes and notify devices |
| Audit events | Who changed what and when, for accountability |
Independent proof, step by step
We will only claim a certification once it has been awarded. This is where we are heading, in order.
Cyber Essentials
UK government-backed baseline certification.
Planned
Independent penetration test
CREST-accredited testing before external customers go live, then annually.
Planned
Cyber Essentials Plus
The independently audited version.
Planned
ISO 27001 and SOC 2
Information security management and controls reporting for larger organisations.
Planned
A review pack on request
Evaluating Interlink Wallet as a supplier? We will walk your team through our architecture, threat model and controls, and answer your questionnaire directly.
- Architecture and data-flow overview
- Threat model and control summary
- Data processing agreement and sub-processor list
- Hosting, backup and incident response details
Responsible disclosure
If you believe you have found a security issue in Interlink Wallet, please tell us privately through our security contact form and include enough detail for us to reproduce it.
We will acknowledge your report, keep you informed while we investigate, and credit you if you wish once it is fixed. Please do not access other people's data, degrade the service or disclose the issue publicly before we have resolved it.
Machine-readable details: /.well-known/security.txt