Let Digiqt identify which of your workloads genuinely need confidential computing and design the attestation and key release around them.

Compute On Data Nobody Else Can See

# Processing Data Nobody Else Can See, Including Your Cloud Provider

Banks have solved two thirds of the data protection problem. Data at rest is encrypted, data in transit is encrypted, and both are routine enough that auditors barely comment. The remaining third is data in use, which has always been decrypted in memory on infrastructure somebody else operates, and which has quietly blocked a long list of otherwise sensible projects.

Confidential computing closes that gap with hardware-enforced isolation. The Confidential Computing Consortium describes it as protecting data while it is in use, closing a data security gap that storage and network encryption leave exposed, using hardware-enforced enclaves such as Intel TDX, AMD SEV, and ARM TrustZone that create isolated execution contexts where even the hypervisor and cloud provider cannot inspect running workloads. Whether that is worth the engineering cost depends entirely on which workload you have in mind.

## What problem does confidential computing actually solve?

It removes the need to trust the operator of the infrastructure with the data being processed.

That is a narrow and valuable property. It does not make data more encrypted at rest, does not improve your access control, and does not address application vulnerabilities. What it does is take the platform operator, and by extension an insider or a compelled disclosure at that operator, out of the set of parties who can read what your workload is computing on.

### What exactly is a trusted execution environment?

A hardware-isolated context where memory is encrypted and the surrounding software stack cannot look in.

The processor enforces isolation, so the host operating system, hypervisor, and administrative tooling see only encrypted memory. Different implementations draw the boundary differently: some isolate a process, others an entire virtual machine, which matters for how much of your application must change. The whole-virtual-machine model is generally easier to adopt because existing workloads fit inside it, while process-level enclaves offer a smaller trusted computing base and demand more redesign.

### Which financial workloads justify it?

Those where the operator's visibility is the specific reason a project cannot proceed.

| Workload | Why confidential computing helps | Alternative to consider first |
|---|---|---|
| Cross-institution analytics on customer data | Compute jointly without exposing raw records | Aggregates or federated learning |
| Model training on sensitive data in shared cloud | Removes provider from the trust boundary | Training on pseudonymised data |
| Processing regulated data where provider access is disallowed | Satisfies a specific access constraint | Sovereign or in-country deployment |
| Key operations and secret handling | Isolation of high-value material | A hardware security module |
| Vendor processing your data on their infrastructure | You verify what runs before releasing data | Contractual controls plus tokenisation |
| Multi-party financial crime analysis | Enables computation none of the parties will host | Privacy-enhancing alternatives |

### When is it the wrong tool?

When cheaper controls address the same risk, which is more often than vendors suggest.

If the concern is your own staff, use access control and monitoring. If the concern is data at rest, encrypt it properly. If the workload can operate on tokenised or masked data, do that instead, since it is simpler and removes the sensitive data entirely rather than protecting it in place, which is the approach set out in this guide to [data masking and tokenisation](https://digiqt.com/blog/test-data-management-banking-pii/). Reserve confidential computing for cases where the operator is genuinely in your threat model and no cheaper control removes them.

> **Is provider visibility the actual blocker on your project, or is it something cheaper to fix?**
>
> [Talk to Digiqt about scoping confidential computing use cases](https://digiqt.com/contact-us/)

## Why is attestation the crux of the design?

Because isolation without verification tells you nothing about what is running inside.

An enclave protects whatever is loaded into it, including code an attacker substituted. Attestation is the mechanism by which a relying party verifies the hardware, the firmware, and a measurement of the loaded workload before trusting it with data or keys. Get attestation wrong and you have an expensive black box with the same trust properties as an ordinary virtual machine.

### What has to be verified before data is released?

Hardware genuineness, firmware and platform state, and a measurement identifying the exact workload.

The relying party checks that the report comes from genuine hardware in an acceptable configuration, that firmware and microcode versions meet policy, and that the workload measurement matches an expected value corresponding to a build you approved. That last part is the operational challenge, because every legitimate code change produces a new measurement, so your build pipeline has to publish measurements as release artefacts and your policy has to be updated in a controlled way. Institutions that skip this end up accepting any measurement, which quietly voids the entire control.

### Who holds the key release policy?

The party whose data is at risk, which is frequently not the party running the workload.

The natural design is that keys are released to an enclave only on successful attestation against a policy the data owner controls. That is what makes vendor processing and cross-institution computation possible: you release the ability to decrypt only to a workload you have verified, running in hardware you have verified. Hold that policy in your own key management regime rather than the operator's, which brings the design back to the custody questions covered in [HSM and key management architecture](https://digiqt.com/blog/hsm-key-management-financial/), and note that FIPS 140-3 remains the relevant certification frame for the modules holding those keys, defining four increasing security levels covering physical security, sensitive parameter management, and self-tests.

## What changes when you design for an enclave?

Memory limits, restricted input and output, sealed debugging, and different operational tooling.

| Constraint | Practical effect |
|---|---|
| Bounded enclave memory | Large in-memory datasets may not fit, requiring streaming or partitioning |
| Restricted system calls and IO | Data must be brought in over authenticated encrypted channels |
| No conventional debugging in production | Failures must be diagnosed from designed-in outputs |
| Observability limits | Logs and metrics must avoid leaking what the enclave protects |
| Attestation lifecycle | Every release changes the measurement and requires policy update |
| Performance overhead | Encrypted memory and transitions cost measurable throughput |
| Operational tooling | Standard agents and sidecars often cannot run inside |

### What breaks when you lift and shift?

Observability first, then anything that assumed a helpful host.

Teams routinely discover that their monitoring agents cannot run inside the enclave, their log pipeline would export exactly the data being protected, and their incident diagnosis process depends on inspecting memory. Design the observability contract deliberately: emit the minimum needed for operations, sanitise it inside the enclave before it leaves, and accept that you will trade some diagnosability for confidentiality. The segmentation and least-privilege reasoning is the same as in this guide to zero-trust security architecture, applied at the process boundary rather than the network.

> **Would your observability pipeline export the very data the enclave protects?**
>
> [Talk to Digiqt about enclave observability design](https://digiqt.com/contact-us/)

## How does this relate to residency and sovereignty?

It changes who can see data, not where data is, so both questions remain.

Confidential computing is frequently sold as a sovereignty answer and it is only part of one. If an obligation concerns the location of processing or the jurisdiction of parties who could compel access, isolation from the operator helps with the second and does nothing about the first. Treat the two separately: use residency architecture for location and jurisdictional exposure, as set out in [data residency and sovereignty architecture](https://digiqt.com/blog/data-residency-architecture-banking/), and use confidential computing to narrow operator visibility where that is the specific concern. Where obligations differ per market, the mapping discipline in this guide to [privacy compliance across jurisdictions](https://digiqt.com/blog/privacy-enhancing-technologies-finance/) applies.

## Where does it enable something genuinely new?

Multi-party computation on data none of the participants will hand over.

This is the most compelling category, because it enables work that simply cannot happen otherwise. Cross-institution financial crime analysis is the clearest example, and the evidence base is encouraging: the BIS Innovation Hub's Project Aurora, reported in May 2023, found that privacy-enhancing technologies combined with network analysis across institutions detected potentially up to three times more complex schemes while reducing false positives by up to eighty percent compared with siloed rules-based approaches. Enclaves are one route to that, alongside the cryptographic techniques discussed in [federated fraud intelligence sharing](https://digiqt.com/blog/federated-fraud-data-sharing/), and the choice between them is usually driven by governance comfort rather than by capability.

## What does the threat model not cover?

Side channels, hardware supply chain trust, your own enclave bugs, and control of attestation policy.

Be precise with stakeholders about the limits. Published research repeatedly finds side-channel and speculative-execution weaknesses in these platforms, so patching discipline for firmware and microcode is part of the control rather than an afterthought. You are trusting the silicon vendor and the attestation service, which is a different trust decision rather than the absence of one. A vulnerability in your own enclave code is fully exploitable inside the enclave, since isolation protects the workload from outside and not from itself. And whoever controls the key release policy effectively controls the confidentiality guarantee, which makes that policy a critical asset with its own access controls and change management.

## How should adoption be sequenced?

One workload, managed service, attestation discipline first, then expand.

Start with a single workload where provider visibility is the documented blocker, and use a managed confidential computing offering rather than building enclave tooling, since the platform work is substantial and rarely differentiating. Establish measurement publishing in your build pipeline and a controlled attestation policy process before anything handles real data, because retrofitting that discipline is how programmes lose the guarantee they paid for. Then measure performance honestly against the non-enclave baseline, and expand only where the constraint genuinely applies. Institutions that declare a general policy of running everything confidentially spend heavily and slow delivery for a benefit most of their workloads do not need.

## Which metrics are worth tracking?

Attestation failure rate, measurement policy currency, performance delta, workload coverage against justified need, and firmware patch latency.

Track attestation failures and their causes, since a rising rate usually means a build or policy process problem rather than an attack. Report how current your accepted measurement list is, because stale policy either blocks legitimate releases or accepts unapproved ones. Measure the performance delta against the same workload outside an enclave so the cost is visible in decisions. Report coverage as the share of workloads with a documented justification, not as a share of the estate, since untargeted adoption is the failure mode here. And monitor firmware and microcode patch latency, because that is the maintenance obligation the guarantee actually depends on.

Confidential computing is a narrow tool that does one thing no other control does, and the institutions that get value from it are the ones that named the workload and the specific trust problem first. Applied that way it unlocks projects that were previously impossible. Applied as a general policy it becomes an expensive way to run ordinary software.

## Frequently Asked Questions

### What problem does confidential computing solve?

It protects data while it is being processed. Storage and network encryption leave a gap during computation, and hardware-enforced enclaves close it by isolating the running workload.

### What is a trusted execution environment?

A hardware-enforced isolated execution context where the workload runs encrypted in memory, so the hypervisor, host operating system, and cloud provider cannot inspect it.

### Which financial workloads justify it?

Cross-institution analytics, model training on sensitive data, processing regulated data in shared infrastructure, and any workload where provider or insider visibility is the unacceptable risk.

### Why is attestation the crux of the design?

Because without verifying what is running inside the enclave, isolation proves nothing. Attestation is what lets a key holder decide whether to release secrets to that specific workload.

### Can you lift and shift an application into an enclave?

Rarely without change. Memory limits, restricted input and output, sealed debugging, and different operational tooling all force design adjustments, and observability usually needs rethinking.

### Does confidential computing solve data residency?

No. It changes who can see data, not where data is. Residency obligations about location and jurisdictional access remain and must be handled separately.

### What does the threat model not cover?

Side-channel research findings, hardware supply chain trust, bugs in your own enclave code, and anyone who controls the attestation policy. Isolation is not a substitute for those controls.

### Where should adoption start?

With one workload where provider visibility is the specific blocker, using a managed confidential computing service rather than building enclave tooling from scratch.

## Sources

- [Confidential Computing Consortium](https://confidentialcomputing.io/)
- [FIPS 140-3, Security Requirements for Cryptographic Modules](https://csrc.nist.gov/pubs/fips/140-3/final)
- [BIS Innovation Hub, Project Aurora](https://www.bis.org/about/bisih/topics/fmis/aurora.htm)

Confidential Computing for Sensitive Financial Workloads

Let Digiqt build your cryptographic inventory and the abstraction that makes the next algorithm transition a configuration change.

Change an Algorithm Without Changing the System

# Replacing an Algorithm Should Not Require Replacing the System

Ask a bank how long it would take to replace one cryptographic algorithm across the estate. Not to design a migration, not to write a policy, just to change from one algorithm to another everywhere it is used. In most institutions nobody can answer, because nobody knows everywhere it is used, and the honest estimate for the parts that are known is measured in years.

That is the real finding behind crypto agility banking systems work. The quantum threat supplies the deadline, but the underlying weakness is that cryptographic choices were made once, hardcoded, and distributed through the estate in ways that make any change a programme rather than a setting.

## What problem is agility actually solving?

The cost of change, which today is high enough that transitions take a decade.

Every previous cryptographic transition in banking has taken far longer than expected, for the same reasons each time: the algorithm is named directly in application code, key material carries no indication of what produced it, protocols negotiate from fixed lists, hardware supports a fixed set, and every counterparty has to move together. Agility means designing so that the next change is a configuration decision and a coordinated rollout rather than a rewrite. That is valuable regardless of quantum computing, because algorithms get deprecated for ordinary reasons too.

### Why does harvest now, decrypt later create a real deadline?

Because the interception happens today and the decryption happens later.

The BIS Innovation Hub's Project Leap, run from the Eurosystem Centre, is explicit about this: malicious actors can intercept and store confidential, classically encrypted data with the intention of decrypting it once quantum computers become powerful enough. The consequence for a bank is that the deadline is not the arrival of a capable quantum computer. It is the arrival of that machine minus the confidentiality lifetime of the data being transmitted now. For payment instructions the useful life is short. For customer identity documents, medical underwriting data, long-dated contracts, and legal records, it is decades, and that data is being transmitted today.

> **How long does your most sensitive transmitted data need to stay confidential?**
>
> [Talk to Digiqt about quantum exposure assessment](https://digiqt.com/contact-us/)

## What is in the cryptographic inventory?

More than the estate documents, and much of it outside your control.

| Where cryptography lives | Typical visibility | Difficulty of change |
|---|---|---|
| TLS termination and internal service traffic | Good | Moderate, mostly configuration |
| Application code calling crypto libraries directly | Poor | High, requires code change |
| Database and storage encryption | Moderate | Moderate, plus re-encryption of data at rest |
| Hardware security modules | Good | Constrained by firmware and certification |
| Code signing and artefact verification | Moderate | Moderate, plus toolchain change |
| Message signing with counterparties | Good | Very high, requires bilateral coordination |
| Certificates and the issuing hierarchy | Good | High, whole chains must move together |
| Vendor products and appliances | Poor | Entirely dependent on the vendor |
| Firmware in cards, terminals, and devices | Very poor | Longest lead time of all |
| Embedded libraries pulled in transitively | Very poor | Requires dependency analysis |

Building this inventory is the first deliverable of any credible programme, and it should record not just where cryptography is used but who controls the decision to change it. That second column is what turns an inventory into a plan.

### Why do the hardest instances sit outside your control?

Because vendor products, firmware, and shared protocols move on someone else's schedule.

A payment terminal fleet, a card estate, an appliance with a five-year support cycle, or a vendor platform with no published post-quantum roadmap all represent exposure that no amount of internal engineering resolves. The practical response is to make it a procurement question now: ask every critical supplier for their cryptographic inventory and transition roadmap, and make agility a contractual requirement for new agreements, which fits into the assessment discipline described in [technology vendor due diligence and exit testing](https://digiqt.com/blog/vendor-due-diligence-banking-technology/). A vendor with no answer today will have no answer when it matters.

## What has actually been standardised?

Two algorithms directly relevant to banking, published together in August 2024.

NIST published FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard, on 13 August 2024. It standardises ML-KEM, which allows two parties to establish a shared secret key over a public channel, with security resting on the difficulty of the Module Learning with Errors problem and believed to hold even against adversaries in possession of a quantum computer. It defines three parameter sets, ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with increasing security strength and decreasing performance.

On the same date NIST published FIPS 204, the Module-Lattice-Based Digital Signature Standard, standardising ML-DSA. It is used to detect unauthorised modification of data, to authenticate the identity of the signatory, and to support non-repudiation, and is likewise believed secure against a large-scale quantum computer. It forms part of NIST's post-quantum standardisation project alongside FIPS 203 and FIPS 205.

| Use in a bank | Traditional approach | Standardised replacement |
|---|---|---|
| Session key establishment | Classical key exchange | ML-KEM (FIPS 203) |
| Signing messages and documents | Classical digital signatures | ML-DSA (FIPS 204) |
| Code and artefact signing | Classical digital signatures | ML-DSA (FIPS 204) |
| Symmetric encryption of data | Symmetric ciphers | Unchanged approach, key sizes reviewed |
| Key derivation and hashing | Hash-based constructions | Unchanged approach, strength reviewed |

The parameter set choice in ML-KEM is a genuine engineering decision rather than a default, since the standard's own framing is that strength increases and performance decreases across the three sets. That trade-off has to be made per use case, informed by the confidentiality lifetime of the data involved.

## What does agility look like architecturally?

Five properties, none of which most estates currently have.

First, no algorithm names in business logic: application code requests an operation such as sign, verify, or establish a session, and a cryptographic service decides how. Second, key material that carries its own metadata, so any stored or transmitted key identifies the algorithm, parameters, and version that produced it. Third, negotiated rather than fixed algorithms in protocols, with the acceptable set expressed as policy. Fourth, cryptographic policy as versioned configuration that can be changed and rolled out without a code release. Fifth, the ability to run two algorithms concurrently during transition, since no realistic migration is instantaneous.

### Why does abstraction fail without algorithm metadata on keys?

Because you cannot decrypt or verify what you cannot identify.

An abstraction layer routes new operations correctly and then meets a key stored five years ago with no record of what created it. At that point the layer has to guess, try each in turn, or fail, and in an estate holding decades of encrypted archives that problem is large. Retrofitting metadata onto existing key material is unglamorous work that has to happen early, because it gates everything else. The custody and lifecycle side of this belongs with the design set out in [HSM and key management for financial workloads](https://digiqt.com/blog/hsm-key-management-financial/).

## What do the performance findings mean?

That post-quantum algorithms cost measurably more, and latency-sensitive paths need designing around it.

Project Leap's results are the most directly relevant evidence available to a bank. Phase 1 successfully tested post-quantum cryptography between two central banks using hybrid encryption combining traditional and quantum-resistant algorithms, proving feasibility while identifying performance impacts requiring further testing. Phase 2, completed in December 2025, demonstrated that replacing traditional digital signatures with post-quantum cryptography works in operational payment systems, while showing that the post-quantum algorithms require significantly higher processing time than traditional algorithms. The project involves the Bank of France and Deutsche Bundesbank, with the Bank of Italy joining in Phase 2, alongside partners including Swift.

For an institution that matters most where time budgets are tight. Instant payment rails with end-to-end targets measured in seconds, high-volume authorisation paths, and card transaction flows all have latency budgets that a slower signature operation consumes. Model the impact per path rather than estimating across the estate, since the answer differs enormously between an overnight batch and an authorisation decision. Where a hub sits on the critical path, its throughput assumptions need revisiting explicitly, as covered in [payment hub architecture](https://digiqt.com/blog/payment-hub-architecture/).

> **Have you modelled what a slower signature operation does to your authorisation latency budget?**
>
> [Talk to Digiqt about post-quantum performance modelling](https://digiqt.com/contact-us/)

## Why use hybrid modes during transition?

Because they stay secure if either algorithm holds.

A hybrid construction combines a traditional algorithm with a quantum-resistant one so that breaking the exchange requires breaking both. That is the prudent posture while operational confidence in the newer algorithms accumulates, and it is the approach Project Leap tested in its first phase. The cost is additional computation and larger messages, which returns to the performance question above. The design decision is where hybrid is worth the overhead, which is usually anywhere the data has a long confidentiality life and anywhere a counterparty requires it.

## What about certificates and hardware?

Both have lead times longer than the software work, so both start earlier.

Certificate hierarchies have to migrate as chains rather than as individual certificates, which means the issuing infrastructure moves first and every dependent system must trust the new chain before anything is reissued. Shorter certificate lifetimes help considerably, because they mean the estate cycles through renewal more often and a transition can ride on the renewal cycle rather than requiring a separate campaign. Hardware is the harder constraint: modules need firmware support, that firmware needs certification, and certification lags standardisation. Ask the supplier for dates in writing, plan replacement cycles around them, and treat any device with a long field life and no upgrade path as a scheduled replacement rather than an open question. Authentication estates carry the same shape of problem, as discussed in [passkey authentication in banking](https://digiqt.com/blog/passkey-authentication-banking/).

## How do you coordinate with schemes and counterparties?

By tracking their roadmaps and accepting that shared paths move together.

No bank migrates a scheme connection unilaterally. Message signing with counterparties, network connectivity, card scheme interfaces, and settlement links all move at the pace of the network, which means the institution's job is readiness rather than initiative: be able to support the new algorithms when the scheme enables them, and have the internal work done so the external step is a configuration change. Maintain a register of external cryptographic dependencies with each party's published position, and escalate the ones with no position. Connectivity paths such as those described in [SWIFT gpi and API connectivity](https://digiqt.com/blog/swift-gpi-api-connectivity/) belong in that register, as do settlement and tokenisation platforms of the kind covered in [tokenised deposits and stablecoin infrastructure](https://digiqt.com/blog/tokenized-deposits-stablecoin-infrastructure/).

## How should the programme be sequenced?

Inventory, then abstraction, then the long-lead items, then transition by data lifetime.

| Phase | Duration | Deliverable |
|---|---|---|
| Cryptographic inventory | 3 to 4 months | Every use, with the party who controls the change decision |
| Data confidentiality lifetime analysis | 1 month | Which flows carry data needing protection for decades |
| Key metadata retrofit | 3 to 6 months | Stored and transmitted keys identify their own algorithm |
| Cryptographic abstraction layer | 4 to 6 months | Business code requests operations, not algorithms |
| Policy as configuration | 2 months | Acceptable algorithm sets deployable without code release |
| Vendor and hardware roadmaps | 2 months, then ongoing | Written positions from every critical supplier |
| Certificate hierarchy readiness | 4 to 6 months | Chains able to migrate, lifetimes shortened |
| Hybrid deployment on long-lifetime flows | 6 to 12 months | Highest-value confidentiality paths protected first |
| Scheme and counterparty readiness | Ongoing | Able to enable new algorithms when the network does |

Sequencing by data confidentiality lifetime rather than by system criticality is the point most programmes get wrong. A less critical system transmitting data that must stay confidential for thirty years is more urgent than a critical system whose data is worthless in a week.

## Which metrics matter?

Inventory completeness, abstraction coverage, key metadata coverage, long-lifetime flow protection, vendor roadmap coverage, and time to change an algorithm.

Report inventory completeness including the proportion where the controlling party is identified. Report how much of the estate calls cryptography through the abstraction rather than directly, since that number predicts the cost of every future transition. Report key metadata coverage, because it gates the rest. Report the share of long-confidentiality-lifetime flows already protected. Report vendor roadmap coverage across critical suppliers. And measure the thing the programme exists to change: how long it would now take to replace one algorithm across the estate. If that figure is not falling, the work is producing migration rather than agility, and the next transition will cost the same as this one. The wider exposure framing for institutions carrying this risk is covered in quantum migration delays.

The quantum timeline is uncertain and the agility work is not wasted under any version of it. An estate that can change an algorithm in months instead of years is better off whatever the physics turns out to allow.

## Frequently Asked Questions

### What is crypto-agility actually solving?

The problem that changing a cryptographic algorithm currently requires changing application code, protocols, hardware, and partner agreements, which makes any transition take years.

### Why does harvest now, decrypt later create a deadline?

Because an adversary can intercept and store encrypted data today and decrypt it once a capable quantum computer exists, so data with a long confidentiality life is already exposed.

### Which post-quantum algorithms have been standardised?

NIST published FIPS 203 standardising ML-KEM for key establishment and FIPS 204 standardising ML-DSA for digital signatures, both on 13 August 2024, alongside FIPS 205.

### Why is the cryptographic inventory never complete?

Because cryptography is embedded in libraries, vendor products, firmware, protocols, and hardware that the institution does not control and often cannot inspect.

### What does crypto-agility look like architecturally?

No algorithm names in business logic, key material that carries its own algorithm identity, negotiated rather than hardcoded algorithms, and cryptographic policy expressed as configuration.

### Do post-quantum algorithms cost performance?

Yes. Central bank experiments replacing traditional digital signatures with post-quantum cryptography in operational payment systems found significantly higher processing time than traditional algorithms.

### Why use hybrid modes during transition?

Because combining a traditional and a quantum-resistant algorithm means the exchange stays secure if either one holds, which is the prudent position while confidence in new algorithms builds.

### Can a bank migrate on its own timetable?

Only for internal systems. Anything crossing a scheme, network, or counterparty boundary moves at the pace of the slowest participant and requires coordination.

## Sources

- [FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final)
- [FIPS 204, Module-Lattice-Based Digital Signature Standard](https://csrc.nist.gov/pubs/fips/204/final)
- [BIS Innovation Hub, Project Leap](https://www.bis.org/about/bisih/topics/cyber_security/leap.htm)

Building Crypto-Agility into Banking Systems Before Quantum

Let Digiqt design HSM and key management architecture that protects the keys that matter without slowing your platforms.

Key Management That Holds Up Under Audit

# Designing Key Management That Survives Audit, Scale, and a Crypto Migration

Key management is the part of a bank's security architecture that nobody looks at until three things happen at once: an auditor asks where a specific key has been since 2019, a payment platform needs ten thousand cryptographic operations a second, and someone senior reads about quantum computing and asks what the migration plan is.

Those three demands pull in different directions. Audit wants ceremony, documentation, and restraint. Scale wants elasticity and low latency. Migration wants agility, which is precisely what heavily ceremonial designs lack. HSM key management for financial workloads is the discipline of satisfying all three without letting any one of them dictate the architecture.

## What does an HSM actually provide?

A certified tamper-resistant boundary where keys are generated and used but never exported in plaintext.

The value is not encryption, which software does perfectly well. It is that the key material cannot leave, so a compromise of your application servers does not become a compromise of your keys. FIPS 140-3, published in March 2019, sets out security requirements for cryptographic modules across four increasing qualitative levels covering module design and interfaces, authentication mechanisms, software and firmware integrity, physical security, sensitive parameter management, self-tests, lifecycle assurance, and attack mitigation. It supersedes FIPS 140-2 and aligns with ISO/IEC 19790:2012 and ISO/IEC 24759:2017, which matters when a vendor quotes a certification level and you need to know what was actually assessed.

### Which workloads genuinely need hardware protection?

Those where key compromise is unrecoverable or where a scheme requires it, not every key in the estate.

| Workload | Hardware module needed | Reasoning |
|---|---|---|
| PIN translation and card cryptography | Yes, payment-specific module | Scheme requirement and unrecoverable compromise |
| Payment message signing and scheme certificates | Yes | Forgery risk and scheme obligation |
| Tokenisation and card data protection | Yes | Protects the data whose loss defines a breach |
| Certificate authority and code signing roots | Yes | Compromise invalidates trust across the estate |
| Database and storage encryption keys | Key-encrypting keys yes, data keys usually not | Hierarchy lets the root sit in hardware |
| TLS termination at scale | Usually not, unless keys are high value | Performance cost rarely justified |
| Passkey and credential verification data | Public keys need integrity, not secrecy | Protect the store, hardware not mandatory |
| Internal service authentication secrets | No, a managed secrets service is appropriate | Rotation matters more than hardware custody |

Being honest about that table is the first cost control in the programme. Treating every key as requiring hardware custody produces an expensive, slow platform that teams route around, which is worse than a focused design they actually use.

### Why does a hierarchy matter more than the module count?

Because a well-designed hierarchy lets a small number of protected roots secure an unlimited number of working keys.

Put root and master keys in hardware, use key-encrypting keys to protect data-encrypting keys, and let data keys live in memory or in encrypted storage where performance demands it. NIST's key management recommendation sets out the protection each type of key requires and the functions involved in administering them, which is the right frame: protection scales with the key's role rather than uniformly. A clean hierarchy also makes rotation tractable, because rotating a key-encrypting key does not require re-encrypting every record.

> **Does every key in your estate get the same protection regardless of its role?**
>
> [Talk to Digiqt about a key hierarchy and HSM scoping review](https://digiqt.com/contact-us/)

## How should key lifecycle and rotation be designed?

With every ciphertext carrying a key identifier, and re-encryption as a supported background operation.

Rotation fails in practice not because generating a new key is hard but because old data still needs reading. If ciphertext does not record which key encrypted it, rotation becomes a migration project every time. Store a key identifier alongside every encrypted value, support multiple active key versions for decryption while only the newest encrypts, and provide a background re-encryption capability that can run without downtime. Then define a cryptoperiod per key type, aligned to its exposure and volume, and treat expiry as an operational event with an owner rather than as documentation. Test the emergency path too: if a key must be replaced today because of suspected compromise, the process should be rehearsed rather than theoretical.

## Which deployment model fits a financial estate?

Usually a hybrid: payment modules on premises, cloud key services for general workloads, one control plane over both.

| Model | Strengths | Trade-offs |
|---|---|---|
| On-premises general purpose HSM | Full physical custody, mature certification | Capacity planning, capex, slower elasticity |
| Payment HSM | Scheme-approved PIN and card functions | Specialised, expensive, limited flexibility |
| Cloud HSM, single tenant | Elastic, no data centre footprint | Physical custody with the provider, exit planning needed |
| Cloud key management service backed by HSM | Simple, cheap, well integrated | Less control over key export policy and tenancy |
| Hybrid with unified control plane | Right protection per workload | Requires disciplined policy to avoid fragmentation |

### What does cloud HSM change about control?

It moves custody rather than removing control, so evaluate export policy, tenancy, attestation, and exit.

The questions that matter are whether keys can ever leave the module and under what conditions, whether the module is single tenant, what attestation you receive about its state, who at the provider could theoretically influence it, how regional availability maps to your residency obligations, and what happens if you need to leave. Answer those explicitly rather than accepting a certification badge as sufficient. Where residency rules apply, model key location alongside data location, since a key in the wrong jurisdiction can undermine an otherwise compliant data architecture, and the segmentation reasoning in this guide to zero-trust security architecture applies to the control plane as much as the network.

### How should ceremonies and dual control be handled?

Scripted, dual controlled, quorum authorised, witnessed, and evidenced, then rehearsed for recovery.

Root key generation and recovery are the moments where process failure has permanent consequences. Script every step in advance, require dual control and split knowledge or quorum authorisation, involve independent witnesses, and produce an evidence pack that satisfies audit without reconstruction later. Then rehearse recovery on a schedule, because ceremonies that have never been executed in reverse are a single point of failure dressed up as a control. Store components securely and separately, and record custody transfers, since the audit question is usually about custody rather than cryptography.

## How do you stop application teams implementing cryptography badly?

By providing a service with safe defaults so nobody needs to make an algorithm choice.

The most common cause of cryptographic weakness in a bank is not a broken module, it is a team that hard-coded a mode, reused an initialisation vector, or logged a key. Expose a small internal service offering encrypt, decrypt, sign, verify, and tokenise, with algorithm selection, key selection, and versioning handled centrally, and never expose raw key material. Then make the service easy enough that using it is the path of least resistance, and prohibit direct HSM access from application code. Non-production environments deserve particular attention, since that is where real keys and real data most often leak, and the practices in this guide to [data masking and tokenisation for non-production](https://digiqt.com/blog/test-data-management-banking-pii/) exist for exactly that reason. Card-specific requirements sit alongside, given that PCI DSS applies to any entity that stores, processes, or transmits cardholder data or could affect the security of the cardholder data environment, as covered in [3-D Secure and tokenisation infrastructure](https://digiqt.com/blog/3d-secure-tokenization-infrastructure/).

> **Can an application team in your bank choose its own cipher mode?**
>
> [Talk to Digiqt about a cryptographic service abstraction design](https://digiqt.com/contact-us/)

## How does performance shape the architecture?

Through explicit operation budgets, session pooling, and keeping hardware calls off the hot path where possible.

Cryptographic operations on a hardware module are fast individually and constrained in aggregate, so treat capacity as a real limit. Budget operations per transaction for each workload, pool and reuse sessions rather than establishing them per request, batch where the operation allows, and use envelope encryption so hardware handles key operations while bulk data encryption happens in software under a data key. Then load test at realistic peaks, including the moments that matter such as payroll windows and card authorisation spikes, because an authorisation path that queues on an HSM under load produces declines that look like a payment platform failure. The response-path constraints described in [card issuing and processing platform architecture](https://digiqt.com/blog/card-issuing-processing-platform/) apply directly here.

## How should post-quantum migration be approached now?

By building a cryptographic inventory and making algorithms configurable, ahead of any specific algorithm decision.

The migration problem is not choosing an algorithm, it is knowing where cryptography lives. Most institutions cannot currently list every place a key is used, which key, with what algorithm and lifetime, across applications, vendors, embedded devices, and archived data. Build that inventory first, because it is the long pole and it is useful immediately for audit and rotation. Then remove hard-coded algorithm choices so a change is configuration rather than a code release, and prioritise long-lived protected data where harvest-now-decrypt-later exposure is real. The strategic risk of leaving this late is the subject of this analysis of [cryptographic obsolescence and migration delays](https://digiqt.com/blog/crypto-agility-banking-systems/), and the passkey and credential estate should be included in the inventory alongside payment keys, as noted in [passkey authentication for financial applications](https://digiqt.com/blog/passkey-authentication-banking/).

## Which metrics prove the platform is healthy?

Inventory completeness, keys past cryptoperiod, rotation success, ceremony rehearsal currency, service adoption, and capacity headroom.

Report inventory completeness as the share of cryptographic usage documented with owner, algorithm, and lifetime, since everything else depends on it. Track keys past their defined cryptoperiod and drive that to zero, because that number is what an auditor will ask for. Measure rotation success and re-encryption backlog. Record when each recovery ceremony was last rehearsed, treating anything beyond a defined interval as a finding. Watch adoption of the central cryptographic service versus direct implementations, since shadow crypto is your real risk surface. And monitor capacity headroom per module against peak load, because that is the metric that turns into customer-visible failure without warning.

## How should delivery be phased?

Inventory and hierarchy first, then the service abstraction, then deployment consolidation, then agility work.

| Phase | Duration | Deliverable |
|---|---|---|
| Cryptographic inventory | 2 to 4 months | Every key usage documented with owner, algorithm, lifetime, location |
| Key hierarchy and policy | 2 months | Roots, key-encrypting keys, data keys, protection per role, cryptoperiods |
| Cryptographic service abstraction | 3 to 4 months | Central encrypt, decrypt, sign, verify, tokenise with safe defaults |
| Deployment consolidation | 3 to 6 months | Right module per workload, unified control plane, residency mapping |
| Lifecycle automation | 2 to 3 months | Rotation, re-encryption, expiry alerting, evidence generation |
| Ceremony and recovery discipline | Ongoing | Scripted ceremonies, scheduled rehearsals, custody records |
| Crypto agility | Ongoing | Configurable algorithms, migration prioritisation for long-lived data |

Start with the inventory even though it is the least satisfying phase. Every later decision, from module sizing to migration sequencing, depends on knowing what you actually have, and institutions that skip it end up sizing hardware for a guess and discovering the real workload during a peak.

Key management is one of the few platform capabilities where the failure mode is silent for years and then absolute. The banks that handle it well are not the ones with the most hardware, they are the ones that know where every key is, protect keys according to their role, and can rotate or replace an algorithm without a project.

## Frequently Asked Questions

### What does an HSM actually provide that software cannot?

A tamper-resistant boundary where keys are generated, used, and never exported in plaintext, with certified physical protection, access control, and self-testing around the module.

### Which workloads genuinely require a hardware module?

PIN and card cryptography, payment message signing, tokenisation, certificate and code signing roots, and any key whose compromise would be unrecoverable. Not every encryption key needs one.

### What do the certification standards cover?

FIPS 140-3 defines four increasing security levels covering module interfaces, physical security, sensitive parameter management, and self-tests, superseding FIPS 140-2 and aligning with ISO/IEC 19790.

### Why does key rotation break systems in practice?

Because data encrypted under an old key still needs reading. Rotation only works when every ciphertext carries a key identifier and re-encryption is a supported background operation.

### Does cloud HSM weaken control?

It changes what you control rather than removing control. You gain elasticity and lose physical custody, so evaluate key export policy, tenancy model, attestation, and exit path explicitly.

### How should key ceremonies be run?

With dual control, split knowledge or quorum authorisation, scripted steps, independent witnesses, and a recorded evidence pack. Then rehearse recovery, because an untested ceremony is a single point of failure.

### How do you stop application teams implementing cryptography badly?

Provide a service with safe defaults: encrypt, decrypt, sign, verify, and tokenise, with algorithms and key selection handled centrally and raw key material never exposed.

### What should we do about post-quantum migration now?

Build a cryptographic inventory and make algorithms configurable rather than hard-coded. Agility is the deliverable, since the specific algorithm choices can follow later.

## Sources

- [FIPS 140-3, Security Requirements for Cryptographic Modules](https://csrc.nist.gov/pubs/fips/140-3/final)
- [NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)
- [PCI Security Standards Council, PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/)

HSM and Key Management Architecture for Financial Workloads

Let Digiqt design insider threat detection that works across trading and banking systems without turning into surveillance nobody trusts.

Detect Misuse Of Access You Granted

# Detecting Harm From People Who Are Supposed to Have Access

Insider threat is the one security problem where every control that normally helps you works against you. Authentication succeeds because the credential is genuine. Authorisation permits the action because someone granted that permission deliberately. No perimeter is crossed, no malware runs, and the activity looks exactly like the job the person was hired to do, because for the most part it is.

That leaves behaviour as the only remaining signal, and behaviour is where privacy, employment law, and organisational trust all become engineering constraints. Building insider threat detection financial institutions can actually defend means being precise about which signals you collect, why, who may see them, and what happens next, before writing any detection logic.

## What counts as an insider threat in a bank?

Misuse of authorised access to critical assets, whether deliberate, careless, or by an attacker wearing a legitimate account.

The SEI's Common Sense Guide to Mitigating Insider Threats, now in its seventh edition published in September 2022, frames the problem exactly that way, presenting twenty-two best practices drawn from analysis of over three thousand insider cases and deliberately addressing management, human resources, legal, physical security, IT, information security, data owners, and engineers. That breadth is the first lesson: a programme owned solely by security will fail, because most of the effective interventions sit outside it.

### Which categories behave differently?

Malicious, negligent, compromised, and third-party insiders need different detection and different responses.

| Category | Typical behaviour | Best detection approach | Response owner |
|---|---|---|---|
| Malicious insider | Deliberate exfiltration, fraud, sabotage, often preceded by grievance or resignation | Behavioural deviation plus contextual signals | Security with HR and legal |
| Negligent insider | Bypassing controls for convenience, mishandling data | Policy violation detection, volume anomalies | Line management and training |
| Compromised account | External actor operating a legitimate identity | Session, device, and pattern anomalies | Security operations |
| Third-party insider | Contractor or vendor staff with granted access | Entitlement review and activity scoping | Vendor management with security |

Conflating them produces bad outcomes in both directions: treating negligence as malice destroys trust, and treating malice as negligence loses evidence. Classify early in triage.

### Why does trading differ from retail banking?

Because the harm is expressed in positions and information rather than in data movement.

In retail and operations, insider harm usually looks like data leaving or accounts being manipulated. On a trading floor it looks like unauthorised positions, mis-marked valuations, limit breaches with delayed reporting, trading ahead of client orders, or information moving to someone who should not have it. Those require signals from order management, position, valuation, and limit systems rather than from endpoint data-movement tooling alone. Institutions that deploy a generic insider tool and skip that integration end up monitoring the least consequential part of their estate.

> **Does your insider programme see position and limit behaviour, or only file movement?**
>
> [Talk to Digiqt about insider signal coverage across trading and banking](https://digiqt.com/contact-us/)

## Which signals are available, and where do they come from?

Access, data movement, business-system behaviour, entitlement change, and context from outside IT.

| Signal source | Examples | Value |
|---|---|---|
| Authentication and access logs | Unusual hours, unusual systems, privilege elevation | High when correlated |
| Entitlement changes | Self-granted access, permission creep, emergency access use | Very high |
| Data movement | Bulk downloads, removable media, unusual destinations | High, with false positive risk |
| Business system behaviour | Payment approvals, limit overrides, valuation adjustments, client data access without a case | Very high |
| Trading behaviour | Position size, cancellations, off-market pricing, timing near client orders | Very high on the floor |
| Audit trail integrity | Attempts to alter or delete records | Decisive when present |
| Context outside IT | Role change, performance process, notice period, prior control breaches | High, and the most sensitive |

### Why is context from outside IT essential?

Because the same technical behaviour means different things depending on circumstance.

A large data download by someone building a report is routine. The same download by someone in a notice period, on a Sunday, from a system they have not used in a year, is not. That correlation is what makes insider detection precise, and it is also what makes it sensitive, because it means joining HR context to technical monitoring. Handle it with a narrow, agreed set of contextual flags rather than broad HR data access, define who may see the join, and document the lawful basis. The integrity of the underlying records matters too, since a programme built on logs that can be edited proves nothing, which is the argument for the patterns in this guide to [event sourcing and immutable audit trails](https://digiqt.com/blog/event-driven-trading-system-architecture/) and for the traceability requirements in [data lineage and audit trail design](https://digiqt.com/blog/audit-ready-ci-cd-financial/).

## How should the detection architecture be built?

Around peer-group baselines, risk scoring across signals, and case-centric aggregation rather than per-event alerting.

Individual baselines catch change but miss the person whose behaviour was always unusual, so compare against peers doing the same job with the same entitlements. Build a role-and-entitlement peer model, score deviation across multiple signal families, and aggregate into a person-level risk view over a rolling window rather than firing an alert per event. That aggregation is what makes the alert volume survivable: a single unusual download is noise, while three signal families lighting up for one person over a fortnight is a case worth an analyst's time.

### How do you avoid drowning the team in alerts?

By scoring people rather than events, requiring corroboration, and tuning against actual case outcomes.

Require at least two independent signal families before a case is raised, weight signals by their historical precision in your own environment, and review closed cases monthly to retire rules that never contribute. Give analysts the evidence in one view, since the cost of a case is dominated by assembling context rather than by making the judgment. And accept a deliberately low case volume: an insider programme producing hundreds of cases a month is not detecting more, it is being ignored.

## Which controls reduce the need for detection at all?

Least privilege with just-in-time elevation, segregation of duties, dual control, and genuine access recertification.

Every unnecessary entitlement removed is an alert you never have to triage and a harm that cannot occur. Standing privileged access is the largest single contributor to insider risk in most institutions, and just-in-time elevation with a reason, an approval, and an expiry converts it into an auditable event. Segregation of duties on payment initiation and approval, on trade booking and confirmation, and on valuation and independent price verification prevents whole categories of harm structurally. Dual control on high-impact actions does the same. And access recertification only helps if reviewers genuinely challenge entitlements rather than approving lists in bulk, which is a process design problem addressed in this guide to [continuous control monitoring](https://digiqt.com/blog/segregation-of-duties-ci-cd-banking/).

### Why is joiner, mover, leaver the recurring weak point?

Because movers accumulate access and leavers keep it longer than anyone believes.

The mover case is the quiet one: someone changes role, gains new entitlements, and keeps the old ones, until a small number of long-tenured staff hold combinations nobody would ever grant deliberately. Automate revocation on role change rather than relying on a manager to request it, alert on entitlement combinations that breach segregation rules, and monitor the leaver window closely, since it concentrates both risk and evidence. Contractor offboarding deserves particular attention, because it frequently depends on a vendor telling you someone has left.

> **How many staff in your bank hold entitlement combinations nobody would approve today?**
>
> [Talk to Digiqt about entitlement analysis and just-in-time access](https://digiqt.com/contact-us/)

## What governance and privacy constraints apply?

Employment and data protection obligations, proportionality, transparency, and strict access control over the monitoring data itself.

Monitoring employees engages legal regimes that vary substantially by jurisdiction, and in several markets it requires consultation with employee representatives before deployment. Settle scope, lawful basis, transparency, proportionality, and retention with legal and HR before building, and write down what is monitored and why in terms employees can read. Then protect the programme's own data as one of your most sensitive datasets, with a small named group, logged access, and independent oversight, because an insider inside the insider programme is the worst case available. Multi-country institutions face the added complexity of differing rules per jurisdiction, which is the terrain covered in this guide to [privacy compliance across jurisdictions](https://digiqt.com/blog/privacy-enhancing-technologies-finance/).

### How do you build a programme employees accept?

By being transparent about scope, proportionate in collection, and consistent in how cases are handled.

Programmes lose legitimacy when they are discovered rather than disclosed, when they collect far more than the stated purpose requires, or when outcomes appear arbitrary. Publish the monitoring scope, keep collection to what the detection genuinely needs, apply the same process regardless of seniority, and give a route for employees to question a decision. The practical benefit is not only ethical: staff who understand and accept the programme report concerns, and colleague reporting remains one of the most effective detection channels available.

## How should cases be handled?

Through a tiered process with joint security, HR, and legal ownership and evidence handled properly from the first minute.

| Tier | Trigger | Handling |
|---|---|---|
| Observation | Single weak signal | Logged, no individual action, feeds tuning |
| Enquiry | Corroborated signals, plausible benign explanation | Line management or control owner clarifies |
| Investigation | Strong corroboration or high-impact system involved | Joint security, HR, legal, formal evidence handling |
| Containment | Active harm indicated | Access restriction with authorised approval, preserve first |
| Referral | Confirmed misconduct or criminality | Legal, regulator notification where required, law enforcement |

Preserve before you contain. Revoking access first is the instinctive move and it frequently destroys the evidence needed to establish what happened, so define the order in the runbook and rehearse it. Also define who may authorise containment out of hours, since an insider case rarely arrives at a convenient time.

## How do you test that the programme works?

By simulating insider behaviour and measuring whether detection fires, in the same way you test external defences.

Run controlled scenarios: an authorised tester performing bulk data access, self-granting an entitlement, approving a payment outside their normal pattern, or booking an off-market trade in a test context. Then measure whether the signal appeared, whether it aggregated into a case, and how long it took. Insider scenarios can also be scoped into a wider threat-led programme, which is the structure described in [threat-led penetration testing](https://digiqt.com/blog/threat-led-penetration-testing-financial/), and the compromised-account category overlaps directly with the session and device signals covered in [behavioural biometrics and device intelligence](https://digiqt.com/blog/behavioral-biometrics-banking/) and the chain analysis in [account takeover prevention](https://digiqt.com/blog/account-takeover-prevention-banking/).

## Which metrics matter?

Tested detection coverage, time to detect, standing privilege reduction, case precision, and entitlement violations closed.

Report which insider scenarios your programme has demonstrably detected in testing, which is far more meaningful than alert counts. Measure time from simulated action to case creation. Track standing privileged accounts and their trend, since reduction there lowers risk without any detection improvement. Report case precision and the share of cases resolved as benign, because a programme with poor precision will lose organisational support quickly. And count segregation-of-duties violations identified and closed, as that is preventive value you can attribute directly.

Insider risk is uncomfortable to work on because it is fundamentally about the people the institution trusts. The programmes that succeed treat it as a control and data engineering problem with strict governance around it, prioritise removing unnecessary access over watching people use it, and are transparent enough that the organisation supports rather than resents them.

## Frequently Asked Questions

### What counts as an insider threat?

Misuse of authorised access to critical assets, whether deliberate, negligent, or by an attacker using a legitimate account. Third parties with insider access belong in the same category.

### Why is detection harder than external threat detection?

Because the activity is authorised. There is no credential anomaly and no perimeter crossing, so detection depends on comparing behaviour with a legitimate baseline rather than spotting intrusion.

### Why does trading need different signals from retail banking?

Because the harm is different. Trading risks include unauthorised positions, mis-marking, and information misuse, so signals come from order and position behaviour rather than from data movement alone.

### What is peer group baselining?

Comparing an individual's activity with others doing the same job rather than with their own history, which catches behaviour that was always unusual instead of only recent changes.

### Which preventive controls reduce the detection burden most?

Least privilege with just-in-time elevation, segregation of duties, dual control on high-impact actions, and regular access recertification. Every access removed is an alert you never have to triage.

### What privacy constraints apply?

Monitoring employees engages employment and data protection law, so scope, transparency, proportionality, retention, and access to the monitoring data itself must be agreed with legal and HR before deployment.

### Who should be able to see insider programme data?

A small, named, audited group. The monitoring system is itself a high-value target and an insider risk, so it needs stricter access control than the systems it observes.

### How do you know the programme works?

Through tested detection of simulated insider behaviour, case outcomes, time to detect, and reduction in standing privileged access, rather than through alert volume.

## Sources

- [SEI CMU, Common Sense Guide to Mitigating Insider Threats, Seventh Edition](https://www.sei.cmu.edu/library/common-sense-guide-to-mitigating-insider-threats-seventh-edition/)
- [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)

Insider Threat Detection Across Trading and Banking Systems

Let Digiqt plan your passkey rollout, including the fallback and recovery design that decides whether it actually improves security.

Go Passwordless Without Locking Customers Out

# Removing Passwords From a Bank Without Locking Anyone Out

Passkeys are the rare security improvement that customers actually prefer. Signing in with the same face or fingerprint that unlocks the phone is faster than typing a password and receiving a code, and the credential cannot be phished. The business case writes itself, and pilots consistently show both better conversion and lower support volume.

Then the programme meets reality. Some customers use browsers without good support, some share a household tablet, some lose the only device holding the credential, and every one of them needs a way in. So the password stays as a fallback, and the phishing route stays open along with it. Delivering passkey authentication banking value depends almost entirely on how you handle that fallback, not on the passkey implementation itself.

## What is a passkey, technically?

A public key credential scoped to your service, held by an authenticator and unlocked locally by the customer.

The FIDO Alliance describes a passkey as an authentication credential based on FIDO standards, stored on a phone or computer, that lets a user sign in with the same biometric or PIN they use to unlock the device, and notes that passkeys are always strong and phishing-resistant because they use standard public key cryptography rather than shared secrets. Your server holds a public key. The private key stays with the authenticator. There is nothing on your side worth stealing and nothing on the customer's side that can be typed into a fake site.

### What does the WebAuthn specification actually define?

Credential creation and use, attestation, user verification, and discoverable credentials.

The W3C Web Authentication Level 2 Recommendation, published in April 2021, defines asymmetric key pairs scoped to a specific relying party, with the public component returned to the service and the private component bound to the authenticator. It defines attestation to attest to the provenance of an authenticator and the data it emits, with several statement formats. It distinguishes user verification, the process by which an authenticator locally authorises the operation through a biometric, PIN, or equivalent, from simpler presence testing. And it supports both client-side discoverable credentials stored on the authenticator, usable without the service first identifying the user, and server-side credentials requiring the service to supply identifiers. Those four concepts are the vocabulary your design decisions will be expressed in, so agree them across security, product, and engineering before implementation starts.

### Should you accept synced or device-bound passkeys?

Both, with different assurance levels attached to each.

FIDO distinguishes synced passkeys, backed up across a user's devices through platform services, from device-bound credentials including security keys that never leave one device and provide the highest level of assurance. Synced passkeys are what make mass adoption realistic, because they survive the device loss that would otherwise strand a customer. Device-bound credentials suit high-value corporate users and staff access. Record which type a credential is at enrolment, and let that inform your risk decisions rather than treating all passkeys as equivalent.

> **Are you planning a passkey rollout without deciding how synced and device-bound credentials will be treated differently?**
>
> [Talk to Digiqt about passkey assurance design](https://digiqt.com/contact-us/)

## What problems do passkeys solve, and what remains?

They eliminate phishing, credential reuse, and shared-secret theft. They do not address deception, recovery, or the call centre.

Credential stuffing stops working because there is no password to reuse. Phishing pages stop working because the credential will not respond to the wrong origin. Interception of one-time codes stops mattering where codes are no longer used. What remains untouched is a genuine customer being socially engineered into acting themselves, which is the intent problem covered in [behavioural biometrics and device intelligence](https://digiqt.com/blog/behavioral-biometrics-banking/), and the recovery and human-channel paths that attackers pivot to once the front door closes, which is the chain analysed in [account takeover prevention](https://digiqt.com/blog/account-takeover-prevention-banking/). Plan for that pivot as part of the programme rather than as a later surprise.

## How should enrolment be designed?

Bound to an already-verified session, offered at a moment of natural friction, with the credential type recorded.

Only enrol a passkey from a session you already trust, since a passkey created during a takeover becomes the attacker's durable credential. Bind enrolment to a strongly authenticated session, and consider requiring step-up before creating the first credential. Then choose the moment carefully: the best conversion comes right after a customer has completed a successful login with the old method, particularly one involving a code they found tedious, because the value proposition is immediately obvious. Encourage a second credential on a second device from the start, as that single habit removes most future recovery cases. Presenting this well is a product design problem as much as a security one, and the adoption patterns in this guide to [self-service portal design](https://digiqt.com/blog/atm-branch-self-service-platform/) apply directly.

### What should be recorded at enrolment?

Credential type, authenticator information where attestation is available, device context, and the session assurance that authorised it.

Store enough to make later risk decisions: whether the credential is synced or device-bound, what attestation reported if provided, the device and platform, and how strongly the enrolling session was authenticated. That record is what lets you require a device-bound credential for a high-value corporate action later, or treat a credential created during a low-assurance session with more caution. Without it, every passkey looks the same forever.

## Why is fallback the whole problem?

Because your effective security level is set by the weakest path you still accept.

If a password and an SMS code remain available to every customer indefinitely, an attacker simply uses that path and your passkey rollout has improved user experience without improving security. That is the uncomfortable arithmetic of every passwordless programme.

### How should fallback be narrowed over time?

By staging removal per segment, with a stronger alternative in place before each removal.

Start by hiding the password rather than removing it, so passkey becomes the default path for enrolled customers. Then restrict which actions a fallback session may perform, so a password login can view balances but not add a payee or change contact details. Then remove password access entirely for customers with two enrolled credentials on separate devices. Then work through remaining segments with supported alternatives, including hardware keys for those who want them and assisted routes for customers who cannot use any of it. Publish the sequence internally so product teams stop treating the password as permanent infrastructure. NIST's guidance is a useful anchor for the assurance reasoning here, particularly its insistence that biometrics are not secrets and must be used alongside a physical authenticator rather than alone.

### How should account recovery work?

As re-proofing to the onboarding standard, with delay and notification, never as a convenience shortcut.

Recovery is the deliberate bypass, so hold it to a genuine evidence standard, add a delay before newly recovered access can perform sensitive actions, notify every previously known contact channel, and log the evidence chain. Offer a supported human or branch route for genuine customers who fail remote recovery, because a strict remote path without an alternative simply converts a security control into a complaints queue. This is also where decentralised and reusable identity approaches start to be genuinely useful, as explored in this guide to [decentralised identity implementation](https://digiqt.com/blog/synthetic-identity-fraud-detection/).

> **Will your password remain available as a fallback indefinitely?**
>
> [Talk to Digiqt about a staged fallback removal plan](https://digiqt.com/contact-us/)

## How do you handle device diversity and shared access?

By supporting multiple credentials per customer and designing explicitly for the awkward cases.

| Situation | Design response |
|---|---|
| Customer with one device only | Encourage second credential, offer hardware key, keep supported recovery route |
| Household or shared device | Multiple credentials on one device, clear per-user verification, never assume one device equals one person |
| Corporate users | Device-bound credentials, administrator-managed enrolment, separation from personal credentials |
| Older or unsupported platforms | Retain a defined alternative path with restricted capability rather than blocking |
| Device replacement | Synced credentials carry over, device-bound require re-enrolment from a trusted session |
| Device loss or theft | Immediate credential revocation, then recovery as re-proofing |

Support several credentials per customer from day one. Single-credential designs look simpler and generate the majority of recovery load, which is the expensive part of running this at scale.

## Should attestation be required?

Request and record it, but do not make it a hard gate for consumer customers.

Attestation tells you what kind of authenticator produced a credential, which is genuinely useful for assurance decisions and for corporate device policy. It is also inconsistently available across consumer platforms, so a strict requirement will block legitimate customers on common devices. Ask for it, store what you receive, use it to inform whether a credential qualifies for high-value actions, and reserve hard attestation requirements for staff and corporate populations where you control the estate.

## How does this interact with regulatory authentication requirements?

Passkeys generally map well onto strong authentication requirements, and the mapping must still be confirmed per jurisdiction.

Most strong customer authentication frameworks require elements from separate categories, and a passkey with user verification typically satisfies possession of the authenticator combined with an inherence or knowledge element resolved locally. That is a favourable position, and it is not something to assume. Take the specific mapping to your compliance function per market, document it, and record the evidence your logs retain to demonstrate it, because the audit question will be about what you can prove rather than what you designed. Server-side, the credential store and its protection belong in the same key management regime as your other cryptographic material, which is covered in [HSM and key management architecture](https://digiqt.com/blog/hsm-key-management-financial/).

## How should rollout be sequenced and measured?

Staff first, then a digital-native segment, then broad rollout, then fallback removal, measured on adoption and support load.

| Phase | Duration | Deliverable |
|---|---|---|
| Internal and staff rollout | 1 to 2 months | Real-world validation on a controlled population |
| Consumer pilot | 2 months | Enrolment flow, conversion measurement, support readiness |
| Broad availability | 2 to 3 months | Default path for supported platforms, multi-credential support |
| Action-based fallback restriction | 1 to 2 months | Password sessions limited to low-risk actions |
| Segment-by-segment password removal | 3 to 6 months | Removal where two credentials exist, alternatives for the rest |
| Recovery hardening | Ongoing | Re-proofing standard, delays, notifications, assisted routes |

Measure enrolment rate by segment and platform, authentication success rate compared with the old method, support contacts per thousand authentications, recovery volume and its causes, the share of sessions still using fallback, and the share of customers holding two or more credentials. That last metric is the leading indicator for everything else, since it determines how fast you can remove the password. Identity lifecycle plumbing underneath all of this is the subject of this guide to [modernising identity and access management](https://digiqt.com/blog/synthetic-identity-fraud-detection/).

Passkeys are worth doing on customer experience grounds alone, and they only improve security to the extent that you eventually close the paths they replace. Plan the rollout as a fallback removal programme with a passkey deployment attached, and the security benefit follows.

## Frequently Asked Questions

### What is a passkey?

A public key credential based on FIDO standards, stored on a device and unlocked with the same biometric or PIN used to unlock that device, replacing a password with a cryptographic key pair.

### Why are passkeys phishing-resistant?

Because the credential is scoped to a specific relying party and the private key never leaves the authenticator, so there is no shared secret an attacker can capture and replay.

### Should a bank accept synced or device-bound passkeys?

Both, with different assurance. Synced passkeys drive adoption because they survive device loss, while device-bound credentials give the highest assurance for high-value actions.

### What is the difference between user presence and user verification?

Presence confirms someone interacted with the authenticator. Verification confirms the authenticator locally authorised the specific user through a biometric or PIN, which is what a bank should require.

### Why is fallback the hardest part of a passkey programme?

Because your effective security equals your weakest available path. Retaining a password or SMS code as fallback leaves the phishing route open regardless of passkey adoption.

### How should account recovery work in a passwordless bank?

As re-proofing against the same evidence standard as onboarding, with a delay before sensitive actions and notification to previously known contact details.

### Do passkeys satisfy regulatory strong authentication requirements?

In most frameworks they map well to possession plus inherence or knowledge, but confirm the mapping with your compliance team per jurisdiction rather than assuming it.

### Should attestation be required at enrolment?

Request it and record it, but avoid hard requirements that block common consumer platforms. Use attestation to inform assurance decisions rather than as a gate.

## Sources

- [FIDO Alliance, Passkeys](https://fidoalliance.org/passkeys/)
- [W3C, Web Authentication Level 2](https://www.w3.org/TR/webauthn-2/)
- [NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management](https://pages.nist.gov/800-63-3/sp800-63b.html)

Passkey Authentication for Banking: A Passwordless Migration Plan

Let Digiqt design containment, egress control, and injection testing for your financial AI assistants.

Assume The Documents Are Hostile

# Treating Everything Your Assistant Reads as Hostile Input

Financial institutions have decades of practice treating user input as untrusted. Every form field is validated, every parameter is bound, every upload is scanned. Language model applications quietly break that discipline, because the content a model reads and the instructions it follows travel in the same channel, so a document your assistant retrieves can tell it what to do.

That is the whole of prompt injection, and it is structural rather than a bug awaiting a patch. The OWASP top ten for large language model applications, whose 2026 list was published in August 2026, ranks prompt injection first, describing manipulation via crafted inputs that can lead to unauthorised access, data breaches, and compromised decision-making. Defending against it in a bank means designing for containment rather than hoping for detection.

## What makes prompt injection structural?

Instructions and data share one channel, so no wording reliably separates them.

| Type | How it arrives | Why it is hard |
|---|---|---|
| Direct injection | A user types instructions attempting to override system behaviour | Detectable in part, but paraphrase and encoding defeat filters |
| Indirect injection | Instructions hidden in retrieved content such as a document, email, or web page | The user is an unwitting carrier and never sees the payload |
| Multi-stage injection | Content instructs the model to plant instructions elsewhere for later | Persists across sessions and users |
| Tool-mediated injection | A tool's response contains instructions the model then follows | Trust is misplaced in your own integrations |

### Why can't prompt engineering solve it?

Because separation of instructions from data is not enforceable in a shared channel.

System prompts telling the model to ignore instructions in documents reduce success rates and do not eliminate them, and each model update changes the picture. Treat prompt hardening as one layer among several, useful and insufficient, and put your engineering effort into limiting what a successful injection can accomplish. That is the same reasoning that made least privilege the foundation of modern security architecture, as set out in this guide to zero-trust security architecture.

## Which attack paths matter in a financial institution?

Anything the assistant reads that someone outside your control can influence.

| Path | Realistic scenario |
|---|---|
| Client-supplied documents | A borrower's financial pack contains hidden instructions, ingested during preparation |
| Inbound email and attachments | An assistant summarising a mailbox reads an attacker's message |
| Web and vendor content | Market commentary or a supplier portal page retrieved for context |
| Third-party data feeds | A field in an external record carries instructions |
| Internal documents authored externally | A contract draft returned by a counterparty |
| Tool and API responses | A compromised or manipulated integration returns instruction text |
| Agent-to-agent messages | One agent's output becomes another's untrusted input |

The first row is the highest-frequency risk in banking, because financial institutions receive documents from outside constantly and process them enthusiastically. Any assistant that reads client documents is exposed by design, which is why the copilot patterns in [relationship manager copilot design](https://digiqt.com/blog/relationship-manager-ai-copilot/) put read-only scope first.

## What is the attacker actually trying to achieve?

Exfiltration, unauthorised action, or influencing a decision, in roughly that order of likelihood.

Exfiltration means getting data out, either directly in output the attacker can see or indirectly through a request to a destination they control. Unauthorised action means using the assistant's tools to do something: create a payee, alter a record, send a message. Influencing a decision is subtler and specific to finance: content crafted so a credit summary omits a weakness or a risk assessment reads more favourably, which harms the institution without any data leaving. That third objective is rarely modelled and deserves to be, because it exploits exactly the trust a copilot is built to earn.

> **Have you modelled an attacker whose goal is a more favourable credit summary rather than stolen data?**
>
> [Talk to Digiqt about an AI assistant threat model review](https://digiqt.com/contact-us/)

## How does data actually leak?

Mostly through outbound calls whose parameters carry the payload.

| Channel | Mechanism | Control |
|---|---|---|
| Outbound tool call parameters | Data placed into a query, URL, or message body | Egress allowlist, parameter validation |
| External fetch or link rendering | Model induced to request an attacker-controlled URL | Block outbound fetches, disable auto-rendering |
| Output to the user | Restricted content surfaced to someone unauthorised | Entitlement-aware retrieval, output checks |
| Logs and traces | Sensitive content copied into log stores with wider access | Redaction, access control on logs |
| Model provider retention | Prompt content retained or used beyond your terms | Contractual and technical verification |
| Error messages | Stack traces and diagnostics carrying data | Sanitised errors |

### Why are outbound calls the main channel?

Because they leave the boundary programmatically and often look like normal operation.

If the assistant can fetch a URL, send an email, write to an external system, or call a search API, then a successful injection has a route out that no output filter inspects. Close it structurally: no arbitrary outbound HTTP, an allowlist of destinations enforced at the network layer, validated parameters per tool, and no automatic rendering of model-supplied links or images. Those controls cost little and remove most of the exfiltration surface, which makes them the highest-return work in this whole area.

## Which defences actually work?

Privilege limits first, then containment, then human gates, then detection.

| Defence | Effectiveness | Notes |
|---|---|---|
| Least privilege on tools | High | An assistant that cannot act cannot be made to act |
| Egress allowlisting | High | Removes the primary exfiltration route |
| Entitlement-aware retrieval | High | Limits what an injection can reach in the first place |
| Human confirmation for sensitive actions | High | Breaks the automated chain at the consequential step |
| Content isolation and structured prompting | Moderate | Clear delineation helps and is not a guarantee |
| Injection classifiers on inputs | Moderate | Catches known patterns, evaded by novel phrasing |
| Output filtering for known sensitive patterns | Moderate | Useful backstop, blind to paraphrase |
| A second model checking the first | Moderate | Adds cost and can itself be injected |
| Prompt hardening | Low to moderate | Necessary hygiene, never the primary control |

The ordering matters. Institutions that invest first in detection classifiers and last in privilege limits end up with an assistant that can do a great deal of damage and a filter that catches yesterday's phrasing.

### What does containment architecture look like?

An untrusted content boundary, with no tool access in the same context as untrusted material.

The practical pattern is to separate the phase that reads untrusted content from the phase that takes action. Retrieve and analyse documents in a context with no tools and no egress, produce a structured summary, then let a separate step act on that structured output with tools available and deterministic validation applied. An injection in the document can corrupt the summary, which is bad, and cannot directly invoke a tool, which is much worse. Add deterministic gates on anything material, so a proposed action is validated against business rules rather than trusted because the model produced it, which is the boundary discipline described in [agentic AI for back-office operations](https://digiqt.com/blog/agentic-ai-banking-operations/).

> **Can your assistant read an untrusted document and call a tool in the same context?**
>
> [Talk to Digiqt about containment architecture for AI assistants](https://digiqt.com/contact-us/)

## How do you test for injection?

With a maintained injection corpus, embedded in realistic documents, run as a regression suite.

Build a corpus of injection payloads covering instruction override, data exfiltration attempts, tool invocation attempts, encoded and obfuscated variants, multi-language payloads, and payloads split across document sections. Embed them in realistic financial documents, since a payload in a bare text file tests less than one hidden in a formatted statement or a contract appendix. Run the suite on every model version, prompt change, and tool addition, because all three change behaviour. Then add adversarial testing by people who did not build the system, and scope AI assistants into your wider threat-led programme, as described in [threat-led penetration testing](https://digiqt.com/blog/threat-led-penetration-testing-financial/).

### What should the suite measure?

Whether the injection succeeded, what it achieved, and whether anything detected it.

Record per payload whether behaviour changed, whether data left, whether a tool was invoked, and whether monitoring alerted. That third column is the one people forget: an injection that succeeds and is detected immediately is a different risk from one that succeeds silently. Track the suite's pass rate over time as a release gate, and treat a regression as a blocking defect rather than a known issue, since the alternative is shipping a capability whose safety properties you have stopped verifying.

## What should production monitoring watch?

Unusual tool patterns, new egress destinations, refusal rate changes, and canary tokens.

Alert on tool call sequences that deviate from normal patterns, on any egress attempt to a destination outside the allowlist, and on sudden changes in refusal or escalation rates, which frequently indicate either a model change or an attack pattern. Plant canary tokens, meaning distinctive fake identifiers, in sensitive records so any appearance of them outside the boundary reveals disclosure. Log prompts, retrieved sources, tool calls, and outputs under one trace so an incident can be reconstructed rather than inferred. And define an incident response path specifically for AI assistants, including who can disable the assistant, because during the first real incident nobody will want to debate that.

## What governance applies?

Inventory, an AI framework, security testing as a release gate, and a defined incident path.

Register assistants in the model inventory, govern them under your own policy plus a recognised framework such as the NIST AI Risk Management Framework 1.0 and its 2024 Generative AI Profile, and use the NIST Cybersecurity Framework, now at version 2.0 released in February 2024, to place the controls inside your existing security programme rather than creating a parallel one. OWASP's list gives you a shared vocabulary with your security function, including sensitive information disclosure at LLM06 and excessive agency at LLM08, which is the entry that most directly warns against giving an assistant unchecked authority to act. Note that OWASP has moved active development to its GenAI security project, so treat the top ten as a widely understood taxonomy rather than a fixed specification. The wider governance framing sits in this guide to [bias and governance in AI systems](https://digiqt.com/blog/model-bias-testing-financial/) and the responsible-deployment patterns in [building responsible generative AI systems](https://digiqt.com/blog/generative-ai-banking-model-risk/).

## How should defence be sequenced?

Privilege and egress first, then containment, then testing, then monitoring, then detection layers.

| Phase | Duration | Deliverable |
|---|---|---|
| Tool and egress lockdown | 2 to 4 weeks | Allowlisted destinations, minimal read-only tools, no auto-fetch |
| Entitlement-aware retrieval | 1 to 2 months | Permission enforced at selection, not display |
| Containment split | 1 to 2 months | Untrusted analysis context separated from action context |
| Injection test suite | 1 month | Corpus, realistic embedding, release gate |
| Monitoring and canaries | 1 month | Tool anomaly alerts, egress alerts, canary tokens, tracing |
| Detection layers | Ongoing | Input classifiers, output filters, second-model checks |
| Incident readiness | 2 weeks | Runbook, kill switch, named owners, rehearsal |

The first row can usually be done in weeks and removes most of the realistic damage, which makes it the right place to start even if the rest of the programme takes months.

## Which metrics matter?

Injection suite pass rate, blocked egress attempts, tool scope, detection rate, and time to disable.

Report the injection regression suite pass rate per release as a gate. Count blocked egress attempts, since a nonzero number confirms the control is active. Track tool scope per assistant, meaning how many actions it can take and how many are irreversible, and drive it down deliberately. Measure detection rate on known payloads, distinguishing prevented from detected. And rehearse and measure time to disable an assistant, because that is your containment capability during an incident and it is invariably slower than anyone expects the first time.

Prompt injection is not a temporary weakness that better models will remove. It follows from mixing instructions and data in one channel, which is what makes these systems useful. The institutions handling it well stopped trying to make the model trustworthy and started making the surrounding system safe when the model is not.

## Frequently Asked Questions

### What is prompt injection?

Manipulating a language model through crafted input so it follows an attacker's instructions instead of yours, which can lead to unauthorised access, data disclosure, or unintended actions.

### What makes indirect injection worse than direct?

The attacker never touches your interface. Instructions hidden in a document, email, or web page reach the model when your system retrieves that content, so the user is an unwitting carrier.

### Can better prompt engineering solve it?

No. Instructions and data share one channel, so no wording reliably separates them. Prompt hardening reduces frequency and cannot be the primary control.

### Where does data actually leak?

Mostly through outbound tool calls and fetches whose parameters carry the data, and secondarily through output to the user, logs, and error messages.

### Which defence gives the most protection?

Least privilege on tools and egress. If the assistant cannot reach an external destination or perform a sensitive action, a successful injection has far less to work with.

### Does output filtering help?

As a secondary layer. It catches known patterns such as card numbers or identifiers leaving, and it cannot catch paraphrased or encoded disclosure, so it must not be the main control.

### How do you test for injection?

With an injection corpus embedded in realistic documents, run as a regression suite on every change, plus adversarial testing by people who did not build the system.

### What should production monitoring watch?

Unusual tool call patterns, egress to new destinations, sudden changes in refusal rates, and canary tokens planted in sensitive records to detect disclosure.

## Sources

- [OWASP Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/)
- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)

Prompt Injection and Data Leakage in Financial AI Assistants

Let Digiqt pressure-test your ransomware recovery architecture, from immutable copies to the sequence you would actually follow.

Recover Without Paying

# Designing a Bank That Can Recover Without Paying

Every bank has backups, and most ransomware victims had backups too. The difference between an institution that restores in days and one that spends a fortnight negotiating is almost never the presence of backups. It is whether the copies were reachable by the same credentials that encrypted production, whether the retention window was longer than the attacker's dwell time, and whether anyone had ever restored an entire service rather than a test file.

Ransomware resilience banking work is therefore less about detection technology and more about a small set of architectural properties that hold up when your identity plane is compromised and your operations team is working from personal phones. The uncomfortable part is that most of those properties can only be proven by testing in a way that makes people nervous.

## What does ransomware resilience actually mean?

Restoring critical services from data the attacker could not reach or alter, within survivable time, without their cooperation.

Note what that definition excludes. It says nothing about preventing intrusion, because prevention will eventually fail, and nothing about paying, because payment is not a recovery strategy and often does not restore service anyway. The NIST Cybersecurity Framework, now at version 2.0 released in February 2024, frames cyber risk management as a set of functions spanning governance through recovery rather than as a perimeter exercise, which is the right mental model: recovery is a designed capability, not the absence of a disaster.

### Why is prevention the wrong primary objective?

Because the failure mode you are planning for is the one where prevention already failed.

Prevention investment reduces frequency and does nothing for severity. Resilience investment reduces severity regardless of how the intrusion happened, which makes it the more defensible allocation once basic hygiene is in place. That framing also changes who owns the programme: recovery capability is an engineering and operations deliverable with a board-level service commitment attached, not a security tooling purchase. The dependency mapping that makes it possible is the discipline described in this guide to [moving from critical-process maps to live dependencies](https://digiqt.com/blog/operational-resilience-impact-tolerance/).

### What does the business actually need to survive?

A defined set of critical services with recovery times the business has agreed and the technology can demonstrate.

Most institutions have recovery objectives per system and no agreed position on which business services must come back first, which is a different question and the one that matters at 3 a.m. Payments, customer access, and the ability to accept deposits usually outrank internal reporting by a wide margin. Get that ordering agreed before an incident, because deciding it live is how recovery efforts fragment across competing demands.

> **Could you name, in order, the first six services your bank would restore?**
>
> [Talk to Digiqt about a recovery sequencing assessment](https://digiqt.com/contact-us/)

## What makes a backup genuinely immutable?

Data that cannot be altered or deleted for a defined window, behind a separate control plane and separate credentials.

Immutability is a property of the whole arrangement rather than of the storage technology, and most failures happen in the parts people do not think of as backup.

| Approach | Protects against | Fails when |
|---|---|---|
| Production snapshots | Accidental deletion, single-system failure | Same account and identity plane as production |
| Object storage with retention lock | Alteration and deletion within the lock period | Lock period shorter than dwell time, or admin can shorten it |
| Separate account or tenancy with isolated credentials | Compromised production identity | Federated to the same directory being attacked |
| Logically air-gapped vault | Network-reachable attack paths | Restore path never tested, credentials stale |
| Offline media | Almost everything technical | Recovery time measured in days, handling process untested |
| Third-party managed vault | Internal compromise | Provider is itself a concentration risk |

### Which properties actually matter?

Separate credentials, a separate control plane, a retention window longer than dwell time, and an immutable catalogue.

Separate credentials means the identity that can delete backups is not derivable from anything in production, including through domain trust or federated single sign-on. A separate control plane means the console, API, and policy that govern retention cannot be reached from a compromised production environment. Retention must exceed realistic attacker dwell time, since encryption frequently occurs weeks after initial access and your most recent copies may already contain the attacker's tooling. And the backup catalogue itself must be protected, because a vault full of data you cannot index is close to useless under time pressure.

### Why do backups fail during real incidents?

Shared identity, encrypted catalogues, insufficient retention, and restores nobody has ever performed at scale.

Those four causes account for the majority of documented failures. The first is architectural, the second is a tooling configuration, the third is a policy decision usually made on cost grounds, and the fourth is a testing failure. All four are visible in advance to anyone who looks, which is why an honest review of these specific properties is the highest-value exercise available before an incident. The cost consequences of getting it wrong compound quickly, as set out in this analysis of what inflates ransomware recovery costs.

## What has to be recovered before anything else?

Identity, key management, and the recovery infrastructure itself.

This is the sequencing error that costs the most time. Teams plan to restore applications and discover they cannot authenticate to the restored infrastructure, cannot decrypt the restored data, or cannot rebuild without a configuration repository that was itself encrypted. Plan and rehearse recovery of the directory and identity provider into clean infrastructure, of key material and secrets, and of the build pipeline and configuration needed to stand systems up. Key recovery in particular needs its own rehearsed ceremony, which is part of why key custody and recovery belong inside the design described in [HSM and key management architecture](https://digiqt.com/blog/hsm-key-management-financial/).

### How should recovery be tiered and sequenced?

By dependency order first, then business priority, with the sequence written down and rehearsed.

| Tier | Contents | Target |
|---|---|---|
| Tier 0 | Identity, key management, DNS, recovery tooling, clean build capability | Hours, before anything else can proceed |
| Tier 1 | Payment processing, customer authentication, core ledger read path | Same day |
| Tier 2 | Full core ledger write path, card authorisation, channels | One to two days |
| Tier 3 | Corporate channels, reporting to regulators, treasury tooling | Days |
| Tier 4 | Internal analytics, non-critical reporting, development environments | Weeks |

Dependency order beats business priority when the two conflict, because restoring a Tier 1 service without Tier 0 simply produces a broken service twice. Write the sequence down, keep it current as architecture changes, and store it somewhere retrievable when your intranet is down.

## How do you test resilience honestly?

By restoring whole services into clean infrastructure using only the runbook and the isolated copies.

| Exercise type | What it proves | Frequency |
|---|---|---|
| File-level restore | The backup tooling works | Continuous, automated |
| Single service restore | One service can be rebuilt from isolated copy | Monthly, rotating |
| Tier 0 recovery rehearsal | Identity and keys can be restored independently | Quarterly |
| Full service-chain recovery | A business service works end to end after restore | Twice yearly |
| Unannounced scenario exercise | Runbooks and people work under pressure | Annually |
| Threat-led testing | Whether an attacker could reach the recovery estate | Per programme cycle |

The last row matters more than it appears. If your red team can reach the backup control plane, your immutability is theoretical, and that is exactly the kind of finding a structured threat-led programme surfaces, as covered in [threat-led penetration testing](https://digiqt.com/blog/threat-led-penetration-testing-financial/). Testing recovery in production-like conditions is also the point of the broader discipline in this guide to disaster recovery for mission-critical platforms.

> **When did your bank last restore an entire business service from an isolated copy?**
>
> [Talk to Digiqt about designing a real recovery exercise](https://digiqt.com/contact-us/)

## How do third parties change the picture?

They can take out your service and your recovery path simultaneously, so critical dependencies need alternatives.

The FSB's toolkit on third-party risk management and oversight, published in December 2023, provides tools for identifying critical third-party services, managing risk across the lifecycle of those relationships, and identifying and monitoring systemic third-party dependencies and concentration risk. Applied to ransomware, the questions are specific: if your recovery depends on a provider, what happens when that provider is the one compromised, what is the alternative, and has anyone tested it. The same applies to software supply chain: a compromised deployment pipeline can reinfect restored systems, which is why clean rebuild capability matters more than restoring the previous state.

## What about the decision to pay?

Decide the position in advance, with legal and executive input, and remove the technical dependence that forces the question.

Whether to pay is a governance decision with legal and sanctions implications that must be settled before an incident rather than during one, and your role as a technology leader is mostly to make the question moot. If recovery is demonstrable, payment becomes a commercial choice rather than a necessity. Also plan for the second demand, which is the threat to publish stolen data, because that pressure survives a perfect restore and needs a communications and legal response rather than a technical one. Recovery capability does not remove extortion leverage entirely, and pretending otherwise leads to unpleasant surprises in the crisis room.

## Which metrics prove resilience rather than activity?

Tested recovery time per tier, immutable coverage, isolation verification, retention against dwell time, and rehearsal currency.

Report tested recovery time rather than target recovery time, because the gap between them is your actual exposure and it is usually large. Track the share of critical services with genuinely isolated immutable copies, verified by attempting deletion with production credentials in a controlled test. Report retention windows against your assumed dwell time. Record when each tier was last rehearsed and treat anything stale as a finding rather than an accepted risk. And measure clean rebuild capability, meaning how long it takes to stand up a service from source in fresh infrastructure, since that is the only path that reliably removes an attacker.

## How should delivery be phased?

Sequence and dependencies first, then isolation, then Tier 0 recovery, then service testing.

Start by agreeing the critical service list and the dependency-ordered recovery sequence, because everything else is scoped by it. Then fix isolation: separate credentials, separate control plane, retention longer than dwell time, protected catalogue. Then build and rehearse Tier 0 recovery, since identity and keys gate everything. Then work through service-level recovery testing tier by tier, fixing what each test reveals. Then add unannounced exercises and threat-led validation of the recovery estate itself. Where recovery depends on cloud infrastructure, the regulatory expectations around it are covered in [cloud migration approval in banking](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/), and the broader core-system recovery patterns are in this guide to disaster recovery for core systems.

Ransomware resilience is one of the few areas where the honest answer to a board question is verifiable. Either you have restored a full business service from an isolated copy recently, or you have not, and every bank that has been through an incident says the same thing afterwards: the test they wished they had run was the one they thought was too disruptive to schedule.

## Frequently Asked Questions

### What does ransomware resilience actually mean?

The ability to restore critical services from data an attacker could not reach or alter, within a time the business can survive, without depending on the attacker's cooperation.

### What makes a backup genuinely immutable?

Data that cannot be altered or deleted for a defined retention window, protected by a separate control plane and separate credentials from the systems it protects.

### Why do backups fail during ransomware incidents?

Because they share credentials or a domain with production, the backup catalogue itself gets encrypted, retention is shorter than the attacker's dwell time, or nobody ever tested a full restore.

### What must be recovered first?

Identity and the recovery infrastructure itself. If your directory, credential store, and key management cannot be restored independently, nothing else can be brought back in a controlled way.

### How long should immutable retention be?

Longer than realistic attacker dwell time, which usually means weeks rather than days, because encryption often happens well after initial compromise and recent backups may already be tainted.

### Is a cloud snapshot an air gap?

No. A snapshot in the same account under the same identity plane is reachable by the same compromised credentials. Isolation is about control planes, not storage location.

### What does a real recovery test include?

Restoring a full service, not a file, into clean infrastructure, using only the runbook and the isolated copies, with the people who would actually be on call doing it.

### How does third-party concentration affect recovery?

A shared provider outage or compromise can take out your service and your recovery route at once, so critical third-party services need identified alternatives and tested exit paths.

## Sources

- [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)
- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)

Ransomware Resilience Banking: Immutable Backup Architecture

Let Digiqt design enforced approval, duty separation, and break-glass paths that satisfy auditors without slowing delivery.

Controls in the Pipeline, Not the Meeting

# Making the Control the Pipeline Rather Than the Meeting

Most banks can produce a segregation of duties policy in under a minute. Producing evidence that the control worked on a specific deployment last Thursday takes considerably longer, and the answer is often a change record that a human filled in describing what they intended to do, alongside a deployment log showing what actually happened, with nothing connecting the two.

That gap is the whole problem. Segregation of duties CI/CD banking controls only mean something when the pipeline itself refuses to proceed, rather than when a committee has been informed.

## What is the control actually trying to prevent?

One person moving a change from their own keyboard into production with nobody else involved.

The risk has two faces. The fraud case is deliberate: someone alters a limit check, a payment beneficiary, an interest rate, or a reporting figure, and deploys it themselves. The error case is far more common: someone deploys the wrong artefact, the wrong configuration, or a change nobody else looked at, and discovers the consequence in production. Both are addressed by the same structural answer, which is that the person who authors a change must not be the person who authorises it or the only person who can release it.

### Why does a change advisory board meeting not deliver this?

Because it approves a description, not an artefact.

A change record says "deploy release 4.2 to production on Thursday" and a board approves it. Nothing in that process establishes that the code in release 4.2 was reviewed by someone other than its author, that the artefact deployed is the one that was built from the reviewed code, or that no additional change was slipped in. The board is a governance forum, and it is useful for scheduling and risk conversation, but treating it as the segregation control produces exactly the evidence gap described above. Control has to attach to the artefact and the identity, which is why it belongs in the pipeline.

## Which duties genuinely need separating?

Four boundaries, and one of them is usually missed entirely.

| Boundary | What it prevents | Common failure |
|---|---|---|
| Author from approver | Self-reviewed change reaching production | Approval by a colleague with no enforced entitlement |
| Build from deploy | Deploying an artefact that was not built from reviewed source | Rebuilding at deploy time from a mutable branch |
| Deploy rights from production data access | A deployer reading or altering customer data | Deployment identities carrying broad database rights |
| Pipeline administration from pipeline use | Changing the control rather than complying with it | Every engineer holding pipeline admin |

The fourth is the one estates miss. An organisation can enforce two-person review on application code while every engineer can edit the pipeline definition that enforces it, which makes the control advisory. The same applies to the identity and entitlement layer generally, which is why this sits alongside the disciplines in [identity and access management for regulated platforms](https://digiqt.com/blog/synthetic-identity-fraud-detection/).

## How do you enforce approval inside the pipeline?

By making the artefact, the approval, and the identity inseparable.

The pattern that works: protected branches that cannot be written to directly, required review from an identity that platform-enforced rules confirm is not the author, a build that produces an immutable versioned artefact from the reviewed commit, a deployment step that can only take an artefact carrying a valid approval, and a deployment identity that is a machine identity rather than a person's credentials. Each link removes a way for the control to be bypassed without leaving a trace. Where a change record system is mandated, tie the deployment gate to the record's approved state programmatically rather than asking a human to confirm it exists.

### Why must the approver be determined by entitlement rather than convention?

Because a convention is unenforceable and unevidenced.

"A colleague reviews it" is not a control. What is a control: the platform knows who authored the change, knows the entitlement group permitted to approve changes to that component, verifies the approver is in that group and is not the author, and records the decision with identity and timestamp. That also handles the awkward cases honestly, such as a two-person team where the only available approver is the author, which the platform should refuse rather than quietly permit. Refusing surfaces a real staffing constraint instead of hiding it behind a signature.

> **Could one person in your organisation author and deploy a change to a payment limit unobserved?**
>
> [Talk to Digiqt about enforced approval and duty separation](https://digiqt.com/contact-us/)

## How do you stop the pipeline becoming the bypass?

Treat pipeline definitions, runners, and secrets as production infrastructure.

Pipeline configuration should live in version control, be subject to the same review requirements as application code, and ideally be reviewed by a group other than the team whose deployments it governs. Build runners need hardened, ephemeral, and isolated execution so one job cannot influence another or reach another team's secrets. Deployment credentials should be short-lived and scoped, issued to the pipeline rather than held by people, with signing material inaccessible to user-defined build steps. Where cryptographic signing is involved the key custody question belongs with the broader design covered in [HSM and key management for financial workloads](https://digiqt.com/blog/hsm-key-management-financial/).

### Why is pipeline configuration the most privileged code you own?

Because whoever changes the pipeline changes what the pipeline enforces.

An engineer who can edit a deployment workflow can remove a review requirement, add a step that pulls an unreviewed artefact, or exfiltrate a secret, and the change looks like ordinary configuration. Privilege should therefore be inverted from the intuitive arrangement: application code review is routine, pipeline change review is stricter. Also monitor for the specific event of a control being weakened, since a commit that removes an approval requirement should generate an alert rather than merely a merge notification. This is the same reasoning that makes dependency and toolchain integrity a first-order concern, as discussed in [software supply chain attacks](https://digiqt.com/blog/threat-led-penetration-testing-financial/).

## What about emergency change?

A defined path, heavily logged, reviewed afterwards, and counted.

Real emergencies happen and a control set with no emergency path will be bypassed informally, which is worse. Define break-glass explicitly: who can authorise it, what it permits, what logging is automatic, and a hard requirement for retrospective review inside a defined period with the same rigour a planned change would have received. Then measure the rate. If ten per cent of production changes go through the emergency path, the standard path is too slow and the exception has quietly become the process, which is a delivery finding rather than a compliance one.

| Break-glass element | Requirement |
|---|---|
| Authorisation | Named individuals, not a role anyone can claim |
| Scope | Specific system and change, time-bounded |
| Logging | Automatic, immutable, including session activity |
| Retrospective review | Mandatory within a defined period, with sign-off |
| Measurement | Rate reported to engineering and risk leadership |
| Trigger for redesign | A sustained rate above an agreed threshold |

## Should anyone hold standing production access?

Almost nobody, and never as a default of employment.

Standing access is the control weakness that most reliably survives a well-designed pipeline, because someone still needs to fix things at three in the morning. Replace it with just-in-time elevation: a request stating purpose, an approval by someone other than the requester, a time-limited grant, automatic revocation, and full session logging. Then reduce the need for elevation by improving observability, since most production access requests are attempts to find out what is happening rather than to change it. The insider dimension is real here and standing broad access is exactly the precondition it needs, which is the subject of [insider threat detection in financial institutions](https://digiqt.com/blog/insider-threat-detection-financial/).

## How do you handle infrastructure and database change?

Same pipeline, same separation, with schema change treated as the sharp end.

Infrastructure defined as code inherits the review and approval model automatically, which is one of the strongest arguments for defining it that way. Database change is harder: a schema migration is code, needs review, and needs a tested rollback or forward-fix path, while direct data manipulation in production should be a break-glass event rather than a routine one. Separate the person who writes a migration from the person who approves it, and separate deployment of a migration from the ability to run arbitrary statements against production. Getting the migration discipline right also matters disproportionately during core replacement work, as covered in [core banking data migration](https://digiqt.com/blog/core-banking-data-migration/).

## What about vendors and offshore teams?

Same entitlement model, with location and jurisdiction as additional attributes.

Vendor engineers frequently end up with broader pipeline and environment access than employees because access was granted at contract start and never reviewed. Bring them into the same entitlement structure, include them in access reviews, and record which entitlements permit approval, since an outsourced author approved by another engineer at the same supplier may not satisfy the separation the institution believes it has. Where the change touches regulated data, the location of the person exercising the entitlement can itself be a constraint, which is the terrain of [data residency and sovereignty architecture](https://digiqt.com/blog/data-residency-architecture-banking/).

## How do you avoid strangling delivery?

Put the control in the path of the change, automate the check, and tier by risk.

The controls above add seconds rather than days when they are automated, and weeks when they are administered by people. The corollary is that risk-tiering matters: a configuration change to a marketing banner should not require the same approval chain as a change to interest calculation. Define standard pre-approved change types with automated verification, a normal path with enforced two-person review, and a high-risk path with additional authorisation. Then measure lead time by tier so it is visible when the control set is the constraint. Confidence in automated testing is what makes tiering defensible, which is why this pairs with [core banking regression automation](https://digiqt.com/blog/core-banking-test-automation/).

Supervisory framing supports the automated direction rather than the committee one. The EBA's guidelines on ICT and security risk management, applicable from 20 May 2025 and amended to align with DORA's application from 17 January 2025, set ICT risk management requirements across credit institutions, investment firms, and payment service providers. PCI DSS applies to any entity that stores, processes, or transmits cardholder data or could affect the security of the cardholder data environment, which brings deployment paths into scope wherever they can reach that environment. And NIST's Secure Software Development Framework, version 1.1 published in February 2022, sets out high-level secure development practices aimed at reducing vulnerabilities and addressing their root causes.

> **Is your emergency change rate above ten per cent of production deployments?**
>
> [Talk to Digiqt about break-glass design and change tiering](https://digiqt.com/contact-us/)

## How should implementation be sequenced?

Version control discipline, then artefact integrity, then gates, then access, then the exceptions.

| Phase | Duration | Deliverable |
|---|---|---|
| Repository and branch protection | 1 month | No direct writes, enforced review from a distinct entitlement |
| Immutable artefacts | 1 to 2 months | Versioned build outputs, no rebuild at deploy time |
| Deployment gates | 2 months | Deploy accepts only approved artefacts, machine identities only |
| Pipeline hardening | 2 months | Pipeline as reviewed code, ephemeral runners, scoped secrets |
| Production access replacement | 2 to 3 months | Just-in-time elevation, standing access removed |
| Database and infrastructure change | 2 months | Migration review, no routine direct data manipulation |
| Break-glass formalisation | 1 month | Defined path, logging, retrospective review, rate reporting |
| Risk tiering | 1 to 2 months | Standard, normal, and high-risk paths with differentiated controls |

Evidence generation is deliberately absent from this list because it is a separate discipline with its own design questions, covered in [audit-ready CI/CD evidence trails](https://digiqt.com/blog/audit-ready-ci-cd-financial/). Enforcement and evidence are related but distinct: this article is about making the control real, that one is about proving it to someone who was not there.

## Which metrics matter?

Self-approved change count, standing production access holders, emergency change rate, pipeline admin population, and lead time by risk tier.

Self-approved changes should be zero and any occurrence should be investigated, since it means an enforcement path failed. Standing production access holders should trend to a small named set. Emergency change rate signals whether the standard path is usable. Pipeline administrator population is the privilege concentration measure. And lead time by risk tier shows whether the controls are proportionate, because if a low-risk change takes as long as a high-risk one then tiering exists on paper only.

Segregation of duties is one of the oldest controls in banking and one of the worst served by traditional change management. It works when the pipeline enforces it, records it, and cannot be quietly reconfigured by the people it constrains.

## Frequently Asked Questions

### What is segregation of duties in a deployment pipeline actually preventing?

One person being able to write a change, approve it, and put it into production unobserved, which is the pattern behind both fraud and uncontrolled error.

### Why does a change advisory board meeting not deliver segregation of duties?

Because it approves a description of a change rather than the artefact being deployed, and it does not prevent the deployer from shipping something different.

### Which duties genuinely need to be separated?

Author from approver, build from deploy, deployment rights from production data access, and administration of the pipeline from routine use of it.

### Why must the approver be determined by entitlement rather than convention?

Because a convention that a teammate reviews the change is unenforceable and unevidenced, while an entitlement check enforced by the platform is both.

### Why is pipeline configuration the most privileged code in the estate?

Because whoever can change the pipeline can change what the pipeline enforces, which makes pipeline definitions a higher-privilege artefact than the application code they build.

### How should emergency change be handled?

Through a defined break-glass path with named authorisation, full logging, mandatory retrospective review inside a set period, and a measured usage rate.

### Should developers have standing production access?

No. Access should be time-limited and requested for a purpose, granted just in time, logged, and revoked automatically when the window closes.

### How do you avoid these controls strangling delivery?

By placing the control in the path of the change rather than the path of the person, automating the check, and risk-tiering changes so low-risk work follows a pre-approved route.

## Sources

- [EBA, Guidelines on ICT and security risk management](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-ict-and-security-risk-management)
- [PCI Security Standards Council, PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/)
- [NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final)

Automating Change Approval and Segregation of Duties in CI/CD

Let Digiqt design PII discovery, masking with referential integrity, and provisioning with expiry for non-production environments.

Realistic Test Data, No Customer Exposure

# Giving Teams Realistic Data Without Copying the Customer Base

Production gets the attention. Access is controlled, changes are reviewed, monitoring is watched, and audits examine it closely. Meanwhile a copy of last month's production database sits in a test environment where thirty engineers and two vendors have access, a subset lives on a laptop, an analytics sandbox holds a year of transactions, and a defect ticket from March has a screenshot showing a customer's full details.

That asymmetry is why test data management banking PII exposure is one of the more likely routes to a reportable incident. The data is the same and the controls are not, and the copies multiply faster than anyone tracks them.

## Where does production data actually end up?

In more places than the environment inventory lists.

| Location | How it gets there | Typical control |
|---|---|---|
| Test and QA databases | Refresh from production | Weak, wide access |
| Analytics and data science sandboxes | Extracts for exploration | Variable, often long-lived |
| Developer machines | Local copies for convenience | Effectively none |
| Vendor and partner environments | Shared for integration or support | Contractual only |
| Log files in non-production | Application logging of real payloads | Rarely reviewed |
| Backups of test systems | Automated backup of the copy | Forgotten entirely |
| Defect tickets and screenshots | Attached evidence of a bug | None, and searchable |
| Training and demonstration systems | Realistic data for credibility | Weak, sometimes public-facing |

The last two deserve attention because they are invisible to database-focused controls. A ticketing system full of screenshots containing customer data is a genuine exposure, and it will not appear in any masking programme scoped to databases.

### Why do copies proliferate?

Because a realistic copy is the fastest way to get work done and nothing charges for the risk.

Engineers need data that behaves like production, refreshing from production is the easiest way to get it, and the cost of that decision falls on the institution rather than the team. Until provisioning masked data is easier than copying production, copying will continue. That makes the programme partly a tooling question and partly an incentive question, and the tooling has to win on convenience rather than on policy.

> **Do you have a current inventory of every environment holding production-derived data?**
>
> [Talk to Digiqt about non-production data exposure assessment](https://digiqt.com/contact-us/)

## What do standards and obligations require?

Identification, classification, protection proportionate to sensitivity, and scope that follows the data.

NIST's guidance on protecting the confidentiality of personally identifiable information, published in April 2010, sets out the approach: identify instances of PII, determine the appropriate level of protection for each instance, apply safeguards proportionate to confidentiality impact levels referencing FIPS 199, and maintain incident response for PII events, while encouraging organisations to tailor the recommendations. Alongside that, PCI DSS applies to all entities that store, process, or transmit cardholder data or could affect the security of the cardholder data environment, which is what pulls a test environment holding real card numbers into scope. Obligations follow the data rather than the environment label, which is the point most non-production estates get wrong.

## What are the techniques, and when does each apply?

Six, chosen by what the environment actually needs.

| Technique | What it does | Best for | Limitation |
|---|---|---|---|
| Static masking | Replaces sensitive values in a copy | Most test environments | Must preserve integrity and format |
| Tokenisation | Substitutes a token with a mapping held securely | Card data, reversible needs | Mapping store becomes sensitive |
| Subsetting | Takes a smaller slice of production | Reducing exposure and cost | Still production data unless masked |
| Synthetic generation | Creates data that never belonged to anyone | Development, volume testing | Realism and rule coverage effort |
| Dynamic masking | Masks at query time for a given user | Production support access | Bypass risk if misconfigured |
| Obfuscation in place | Transforms values within an environment | Remediating an existing copy | Original may persist in backups |

Most estates need a combination: synthetic data for development and volume testing, masked subsets for integration and user acceptance testing, and dynamic masking for production support. The generation side is covered in [synthetic data generation for financial services](https://digiqt.com/blog/synthetic-data-financial-services/), and the masking techniques in this guide to data masking and tokenisation for non-production.

### Why must masking preserve referential integrity and format?

Because inconsistent masking produces data that fails tests for reasons unrelated to the code.

A customer masked as one value in the account table and another in the transaction table breaks every join, producing defects that do not exist in production and hiding ones that do. Masking must therefore be deterministic across tables, systems, and refreshes so the same input yields the same masked output everywhere, while remaining irreversible without the key. Format matters equally: a masked identifier that fails a checksum, a date that breaks an age rule, or a name with characters the application rejects will cause failures that get blamed on the masking programme and used to justify going back to production copies.

### Is anonymised data automatically out of scope?

Not unless it survives re-identification testing.

Removing direct identifiers does not necessarily prevent identification, since rare attribute combinations can single out individuals, and a dataset containing one customer with an unusual balance in a small postcode identifies that person to anyone who knows them. Test for it: measure uniqueness of attribute combinations, apply generalisation or suppression to outliers, and document the assessment. Claiming anonymisation without that testing is a position that will not survive scrutiny, and it is the assumption most commonly relied upon.

## How do you discover and classify PII at scale?

By scanning content rather than trusting schemas, and by rescanning because estates drift.

Automated discovery should inspect actual values with pattern and context analysis rather than relying on column names, since sensitive data appears in columns named `field7` and absent from columns named `customer_name`. Cover unstructured content too: documents, attachments, log files, and free-text fields. Then rescan on a schedule, because new tables, new fields, and new integrations arrive continuously and a classification completed last year describes an estate that no longer exists.

### Why do free-text fields defeat schema-based classification?

Because a notes field contains whatever a colleague typed, including full identity details.

Customer service notes, complaint records, and case narratives routinely contain names, account numbers, dates of birth, and sometimes card details entered for convenience. No schema analysis finds that, and masking a notes field wholesale destroys its testing value. The workable approach is content-level detection with redaction of identified entities, accepting imperfection, and treating any environment containing free-text customer content as higher risk regardless of the masking applied elsewhere.

## How should provisioning work?

Self-service, versioned, entitlement-controlled, and expiring by default.

Make requesting a masked dataset faster and easier than copying production, since that is the only durable way to change behaviour. Provide versioned datasets so tests are reproducible, a refresh cadence that keeps data useful, size options so a developer can take a small slice rather than everything, and an entitlement model determining who may request what. Then set expiry by default with automatic deletion, and require justification to extend.

### Why does expiry matter more than provisioning speed?

Because fast provisioning without lifecycle control simply creates more copies.

An estate where anyone can obtain a masked dataset in minutes and nothing is ever deleted accumulates exposure faster than the old process did, just with masked data. Expiry, automatic deletion, and an inventory of live datasets with owners are what make the programme a net reduction in risk. Report datasets past their expiry as a standing metric, because that number is the honest measure of whether lifecycle control is working.

> **Do your provisioned test datasets expire automatically, or persist until someone remembers?**
>
> [Talk to Digiqt about provisioning workflow and dataset lifecycle](https://digiqt.com/contact-us/)

## How should environments and access be controlled?

Segmented, entitlement-based, without production credentials, and logged.

Non-production environments should be network-segmented from production with no shared credentials, no production service accounts, and no route by which a test system can reach production data. Access should follow entitlements reviewed like any other, including vendor and contractor access which is frequently the widest and least reviewed. Log access to environments containing production-derived data, because if an incident occurs the first question is who could see it and the second is who did. Insider risk applies here as much as anywhere, and non-production is where standing broad access is most common, which is the pattern discussed in [insider threat detection](https://digiqt.com/blog/insider-threat-detection-financial/).

## How should production support access be handled?

Through masked views by default, with a controlled break-glass path for the rest.

Support engineers sometimes genuinely need to see a specific customer's data to resolve an issue, and the answer is not a production copy in a test environment. Provide masked or aggregated views that answer most questions, then a break-glass path for the remainder: named approval, time-limited, scoped to specific records, fully logged, with session recording where appropriate. Measure break-glass usage, since a high rate means the masked views are inadequate and the exception has become the process. Residency and jurisdictional constraints apply to support access too, as covered in [data residency and sovereignty architecture](https://digiqt.com/blog/data-residency-architecture-banking/).

## How do you evidence compliance?

Through environment inventory, classification coverage, masking verification, and access records.

Maintain an inventory of every environment holding production-derived data with its owner, contents, classification, and control state. Report classification coverage across the estate. Then verify masking rather than assuming it: run automated checks against masked datasets looking for unmasked patterns such as valid card numbers, real identifiers, plausible names in fields that should be masked, and referential inconsistencies. Treat any finding as an incident with root cause analysis, because a masking process that silently misses a column has been providing false assurance for however long it has run.

### What does masking verification look like in practice?

Automated scanning of masked output for anything that looks real, run every time.

Build the verification into the provisioning pipeline so a dataset cannot be released if it fails, and include checks for the awkward cases: partially masked fields, data embedded in free text, values in log tables, and references in identifier columns nobody classified. Publish the results, since verification evidence is what turns a masking claim into a demonstrable control. The programme framing and delivery considerations are covered in this guide to test data management in software delivery.

## How do you handle the hardest cases?

Volume testing, defect reproduction, and model training each need a specific answer.

Performance testing at production volume is best served by synthetic generation, since realism of individual records matters less than distribution, cardinality, and volume. Defect reproduction that genuinely requires specific real data goes through the break-glass path with approval, scoping, and logging rather than through an informal copy. Model training on customer data is a separate discussion with its own lawful basis, and where synthetic augmentation is used the provenance must be documented. Multi-jurisdiction estates add constraints on where any of this data may sit, which is the terrain of this guide to [privacy compliance across jurisdictions](https://digiqt.com/blog/privacy-enhancing-technologies-finance/).

## How should delivery be sequenced?

Inventory and discovery, then masking with integrity, then provisioning with expiry, then the exceptions.

| Phase | Duration | Deliverable |
|---|---|---|
| Environment inventory | 1 to 2 months | Every environment holding production-derived data, with owners |
| Discovery and classification | 2 to 3 months | Content-based scanning including free text and documents |
| Masking with referential integrity | 3 to 4 months | Deterministic, format-preserving, cross-system consistent |
| Masking verification | 1 to 2 months | Automated checks as a release gate on every dataset |
| Self-service provisioning with expiry | 2 to 3 months | Versioned datasets, entitlements, automatic deletion |
| Legacy copy remediation | 2 to 4 months | Existing unmasked copies removed or masked in place |
| Support access model | 2 months | Masked views plus logged, approved break-glass |
| Synthetic data for volume and development | 3 to 4 months | Generation with business rule validity |

Legacy remediation matters as much as the new capability. A programme that provisions masked data beautifully while three unmasked copies from 2023 remain in test environments has not reduced exposure, and those copies are exactly what an incident or an audit will find.

## Which metrics matter?

Environment inventory completeness, unmasked copies remaining, masking verification failures, datasets past expiry, break-glass usage, and provisioning lead time.

Report inventory completeness and classification coverage, since everything else depends on knowing what exists. Track unmasked production copies remaining as the headline risk number, driving it to zero. Report masking verification failures as incidents with causes. Count datasets past expiry, which measures lifecycle discipline. Track break-glass access volume and whether it is trending down as masked views improve. And measure provisioning lead time, because if the compliant path is slow the non-compliant path will continue, and that behavioural fact determines whether the programme succeeds.

Non-production data is the part of a bank's estate where the data is production-grade and the controls are not. Fixing it is mostly unglamorous: know every environment, classify by content rather than by schema, mask deterministically, verify the masking every time, and make the compliant path the fastest one available.

## Frequently Asked Questions

### Why is non-production the weakest link?

Because it holds production-derived data with weaker controls, wider access, and copies nobody tracks, while attracting a fraction of the security attention production receives.

### Where does production data actually end up?

Test databases, analytics sandboxes, developer machines, vendor environments, log files, backups of test systems, and attachments on defect tickets and screenshots.

### Why do non-production copies pull environments into compliance scope?

Because obligations follow the data. PCI DSS applies to any entity storing, processing, or transmitting cardholder data or able to affect the cardholder data environment.

### Why must masking preserve referential integrity?

Because a masked customer must be the same masked customer across every table and system, or the data becomes useless for testing and defects appear that do not exist.

### Why do free-text fields defeat schema-based classification?

Because a notes field can contain anything a colleague typed, including full identity details, so classification must inspect content rather than trust column names.

### Is anonymised data automatically outside scope?

Not unless it withstands re-identification testing. Rare records and combinations of attributes can identify individuals even when direct identifiers are removed.

### What matters more than provisioning speed?

Expiry and deletion. Fast provisioning without lifecycle control simply produces more copies, which increases exposure rather than reducing it.

### How should defect reproduction needing real data be handled?

Through a controlled, time-limited, logged path with masked views where possible and named approval where not, never through an informal copy to a developer environment.

## Sources

- [NIST SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information](https://csrc.nist.gov/pubs/sp/800/122/final)
- [PCI Security Standards Council, PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/)

Test Data Management in Banking Without Exposing Production PII

Let Digiqt help you scope, run, and act on a threat-led testing programme that produces findings worth fixing.

Test Like The Adversary You Actually Face

# Running a Red Team Exercise That Tells You Something You Did Not Know

Most banks buy a lot of security testing and learn very little from it. Scanners find missing patches, annual penetration tests find the same categories of weakness in a different application each year, and none of it answers the question a board actually asks: if a capable adversary targeted our payment operation next month, would we notice, and would we stop them.

Threat-led penetration testing exists to answer exactly that. It is structured, intelligence-driven, run against production, and deliberately measured on what your defenders detect rather than on a list of vulnerabilities. Running it well is mostly a matter of governance and follow-through, because the technical execution is the part your testing provider already knows how to do.

## How is threat-led testing different from a penetration test?

It simulates a specific adversary against critical business functions in production, rather than probing a defined system for weaknesses.

| Dimension | Penetration test | Threat-led test |
|---|---|---|
| Scope | A named application or environment | Critical business functions end to end |
| Environment | Frequently test or staging | Production |
| Driver | A checklist and a scope document | Tailored threat intelligence on your actual adversaries |
| Target set | Technology | People, process, and technology together |
| Defender awareness | Usually informed | Deliberately unaware |
| Primary output | Vulnerability list | Attack paths, detection gaps, and response performance |
| Success measure | Findings closed | Learning and maturity improvement |

### What does the TIBER-EU framework define?

A phased process with five defined teams, developed by the ECB and EU national central banks and published in May 2018.

TIBER-EU stands for Threat Intelligence-Based Ethical Red-Teaming in Europe. It was approved by the ECB's Governing Council, published in May 2018, updated in 2024 to align with digital operational resilience requirements, and has been adopted across more than twenty European jurisdictions. Tests mimic the tactics, techniques, and procedures of real-life attackers against an entity's critical functions across people, processes, and technologies, and proceed through initiation and scoping, threat intelligence gathering, red-team testing, and reporting and remediation. The United Kingdom runs a comparable threat intelligence-led scheme, CBEST, overseen by its authorities, and the structural pattern is deliberately similar across regimes, so a programme built to one framework transfers with modest adaptation.

### Why is there no pass or fail?

Because a pass would be meaningless and a fail would make institutions hide findings.

TIBER-EU explicitly emphasises learning outcomes and advancing cyber maturity rather than pass or fail scoring. That design choice is what makes honest testing possible: if a test could fail, every incentive would push toward narrow scope, forewarned defenders, and quiet findings. Preserve that principle internally too. If your executive committee treats a successful simulated compromise as a performance failure rather than as the expected result of a well-scoped test, your programme will quietly degrade into theatre within two cycles.

> **Does your leadership treat a successful red team as a finding or as a failure?**
>
> [Talk to Digiqt about setting up a threat-led testing programme](https://digiqt.com/contact-us/)

## Who does what during a test?

Five roles, with the control team carrying most of the organisational risk.

| Team | Role | Knows the test is happening |
|---|---|---|
| Blue team | The institution's defenders and responders being measured | No |
| Threat intelligence provider | Produces the targeted threat landscape and scenarios | Yes |
| Red team | Executes the simulated attack | Yes |
| Control team | Small internal group coordinating and containing the test | Yes |
| Authority cyber team | Oversees framework compliance where a regulator is involved | Yes |

### Why does the control team determine whether the exercise works?

Because it manages scope, guardrails, escalation, and the moment when a real incident and a test collide.

The control team decides when to intervene, holds the kill switch, and handles the situation where the blue team escalates a genuine incident during the test window or where the red team's activity risks customer impact. Staff it with people senior enough to stop the exercise and technical enough to understand what is happening, keep it deliberately small, and rehearse the escalation path before day one. Also decide in advance how you will distinguish a real attack from the test, because that ambiguity is genuinely dangerous and it has caught out well-run programmes.

### What should the blue team learn, and when?

Everything, immediately after the test, in a session designed for learning rather than accountability.

The value of the unaware response evaporates if it turns into a blame exercise afterwards. Run a joint replay where the red team walks through the attack path and the blue team walks through what they saw, when, and why they interpreted it as they did. The most useful findings usually come out of that comparison: an alert that fired and was closed, a signal that existed in a tool nobody watches overnight, a runbook step that assumed information the responder did not have.

## How should scope be set?

Around critical business functions in production, with defined guardrails rather than defined targets.

Scope by outcome, not by system. The scenario should be an objective an adversary would pursue, such as effecting an unauthorised payment, exfiltrating customer data at scale, or degrading a critical service, and the red team should be free to find the path. Naming specific systems as targets invites the team down a route you already worry about, which is precisely where you least need assurance.

### Why must the test run against production?

Because your test environments do not have your people, your monitoring, or your accumulated configuration drift.

Real adversaries face your actual estate, including the legacy service nobody documented and the monitoring gap that exists because a tool was migrated last quarter. Testing a staging environment measures a system you built for testing. Production testing needs guardrails: prohibited actions defined in writing, a kill switch reachable at any hour, data handling rules for anything the red team encounters, and pre-agreed legs-up so that a blocked path does not consume the engagement. Those controls make production testing routine rather than reckless.

### How do you keep the exercise from wasting itself on one obstacle?

With planned legs-up and time-boxed objectives agreed with the control team.

If the red team spends three weeks on initial access and never reaches the interesting part of the estate, you have paid to learn one thing you probably already suspected. Agree in advance that after a defined period the control team may grant assumed access at a specified level so the exercise can proceed to lateral movement, privilege escalation, and objective execution. Record where the leg-up was given, because that itself is a finding about where your controls held.

## How does threat intelligence drive the scenarios?

By identifying the adversaries plausibly interested in your institution and the techniques they actually use.

A useful targeted threat intelligence report names relevant threat actors, describes their observed tradecraft, maps it to your attack surface, and proposes scenarios grounded in that pairing. A poor one recycles generic industry reporting into a document nobody reads. Insist on specificity about your institution: your suppliers, your technology choices, your public footprint, your staff exposure. Then use the intelligence to prioritise which paths get exercised, since no engagement covers everything and the choice of what to simulate is the most consequential decision in the whole programme. Patch and exposure timing feeds this directly, as discussed in this analysis of vulnerability exploitation windows.

> **Is your threat intelligence specific to your institution or recycled industry reporting?**
>
> [Talk to Digiqt about intelligence-led scenario design](https://digiqt.com/contact-us/)

## How should findings be handled?

As engineering work with owners, dates, and architectural consequences, not as a report to be accepted.

Separate findings into three classes and treat them differently. Detection gaps go to the security operations backlog with a specific detection to build and a test to prove it. Architectural weaknesses, such as a flat network or an over-privileged service account, go into engineering roadmaps with the recognition that they may take quarters. Process and people findings go to the owners of those processes. Then track all of them to closure with the same rigour you apply to production defects. Programmes fail here more than anywhere else: findings are accepted, partially remediated, and reappear in the next cycle, which is how institutions end up paying for the same lesson three times. Remediation of segmentation and privilege findings usually points back to the model described in this guide to zero-trust security architecture.

### What makes a finding worth the cost of the exercise?

One that changes an architecture decision or creates a detection you did not have.

A credential in a file share is a fix. An attack path that shows your payment operation is reachable in three steps from a marketing laptop is a strategic finding, and it is what you paid for. Judge each engagement on how many findings of the second kind it produced, and if the answer is zero, question the scope rather than concluding you are secure. Testing whether the adversary could reach your recovery estate is a particularly valuable objective, since immutability that a red team can defeat is not immutability, which connects directly to [ransomware resilience and immutable backup design](https://digiqt.com/blog/ransomware-resilience-banking/) and to the cost dynamics in [what inflates ransomware recovery costs](https://digiqt.com/blog/ransomware-resilience-banking/).

## How does this fit alongside other assurance?

As the apex of a pyramid, not a replacement for continuous testing.

Continuous vulnerability management and configuration scanning handle volume. Regular penetration testing covers application and infrastructure depth. Purple team work builds detections collaboratively and is often the cheapest way to close gaps found by red teaming. Threat-led testing validates the whole system, including your people, once or twice a year. Continuous control validation sits underneath, checking that the detections you built still fire. Each layer feeds the next, and running only the top layer produces expensive theatre while running only the bottom produces confidence without evidence. Framing the programme against a recognised structure such as the NIST Cybersecurity Framework, now at version 2.0 released in February 2024, helps the layers stay coherent and gives you common vocabulary with auditors.

## What about third parties and shared infrastructure?

Scope them deliberately, with contractual permission, because your critical functions run partly outside your perimeter.

Critical functions frequently depend on providers you cannot test unilaterally, and testing a third party without authorisation is not an option. Address it in three ways: include the third-party interface and your own controls around it in scope, obtain contractual rights to assurance evidence and where possible joint testing, and treat concentration explicitly. The FSB's December 2023 toolkit on third-party risk management provides tools for identifying critical third-party services and for monitoring systemic dependencies and concentration risk, which is the right frame for deciding which providers justify the negotiation effort.

## How do you budget and schedule a programme?

One major exercise per year for most institutions, with intelligence refresh, remediation cycles, and purple team work between.

| Activity | Typical cadence | Main cost driver |
|---|---|---|
| Targeted threat intelligence | Annually, refreshed before each test | Specificity and analyst time |
| Red-team engagement | Annually, six to twelve weeks elapsed | Team size and scenario breadth |
| Replay and findings workshop | Immediately after each test | Internal time, not vendor cost |
| Remediation delivery | Continuous | Architectural findings dominate |
| Purple team detection building | Quarterly | Internal capability |
| Regulatory reporting where applicable | Per framework cycle | Documentation quality |

Budget for remediation, not just testing. A programme that funds the exercise and not the fixes produces a well-documented list of unaddressed weaknesses, which is worse than not testing because it establishes that you knew.

## Which metrics show the programme is maturing?

Detection rate along the attack path, time to detect and contain, repeat findings, and remediation closure.

Measure how far the red team progressed before detection, and track that across cycles, since improvement means detection moving earlier in the chain. Report time from first red team action to detection and to containment. Count repeat findings from previous cycles as a direct measure of remediation effectiveness, and treat any repeat as an escalation rather than a note. Track closure rate and ageing of findings by class. And record the number of new detections built as a result of each exercise, because that is the durable capability the programme leaves behind after the report is filed.

Threat-led testing is the only assurance activity that tells you how your institution behaves under a realistic attack rather than how your systems score against a checklist. It earns its cost when the findings change architecture and detection, and it wastes it entirely when the report is accepted, circulated, and quietly filed.

## Frequently Asked Questions

### How is threat-led testing different from a penetration test?

A penetration test looks for weaknesses in a defined system. Threat-led testing simulates a specific adversary against critical business functions in production, across people, process, and technology.

### What does the TIBER-EU framework define?

A structured process with initiation and scoping, threat intelligence, red-team testing, and reporting and remediation phases, run by five defined teams, with learning rather than pass or fail as the outcome.

### Why is there no pass or fail?

Because a pass would be meaningless and a fail would push institutions toward narrow scope and hidden findings, which destroys the value of testing honestly.

### Why does the test have to run against production?

Because attackers do. A test environment tells you about a configuration you built for testing, not about the systems, people, and monitoring that actually protect your critical functions.

### Who should know a test is happening?

A small control team, deliberately excluding the defenders being tested. The blue team's unaware response is the primary thing being measured.

### How do you manage the risk of testing live systems?

Named guardrails, a real-time kill switch, agreed prohibited actions, a control team with authority to stop, and pre-planned legs-up so a blocked path does not waste the engagement.

### What makes a finding worth the exercise?

One that changes an architectural decision or a detection capability, not another credential in a file share. Value comes from the attack path, not the individual weakness.

### Why do these programmes stall?

Remediation. Findings are accepted, partially fixed, and reappear in the next cycle, so track them to closure with owners and dates like any other engineering work.

## Sources

- [ECB, TIBER-EU framework](https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html)
- [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)
- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)

Posts tagged with#Security