Surface
Most fintech security reviews start with a compliance checklist and end with a long backlog nobody owns. A crypto threat model starts somewhere sharper: which secrets, which messages, and which trust boundaries, if broken, move money or leak data that stays valuable for a decade.
This post follows crypto-agility in 2026. Agility without a threat model produces random migrations. Threat models without agility produce beautiful diagrams that still cannot rotate when a primitive fails. Together they tell you what to harden first and what you must be able to swap.
Start with assets that have cryptographic life
Write down what you protect before you name attackers:
- Signing keys that authorize payments, withdrawals, or contract upgrades
- Encryption keys wrapping customer PII, statements, and KYC artifacts
- Session and API credentials that sit one step away from those keys
- Long-lived ciphertext in backups and partner archives (the harvest-now-decrypt-later target)
- Protocol transcripts that an adversary might replay or downgrade
Financial services have historically ranked among the highest average breach-cost industries in IBM’s Cost of a Data Breach research. Whether the global average sits near $4.88M (2024) or about $4.44M (2025), the relevant point for your model is local: a custody key compromise or mass decryption of archived PII is not a “medium” ticket.
Adversaries worth modeling in 2026
Skip generic “hacker” personas. Name capabilities:
1. Opportunistic attackers aiming at misconfigured APIs, leaked cloud keys, and phishing into ops consoles 2. Organized fraud rings specializing in social engineering of recovery flows and support staff 3. Insiders with legitimate HSM or MPC operator roles 4. Nation-state or advanced collectors storing ciphertext for future cryptanalysis (especially relevant as NIST’s PQC standards land and IR 8547 points toward 2035 deprecation paths) 5. Malicious or compromised partners under EU MiCA CASP obligations who still become part of your trust boundary when you exchange keys or encrypted payloads
Map threats to failure modes, not only to OWASP labels
Rank by financial blast radius
Withdrawal signing key
Single laptop PEMHSM/MPC + dual control
Long-lived archives
One-shot RSA wrap foreverRe-wrap + PQC plan
Partner instructions
Any suite acceptedAllowlists + downgrade alerts
Support tooling
Standing admin sessionsShort-lived + step-up auth
Insight: fund rotation for money-moving and long-lived-data threats before exotic protocol work that does not change blast radius.
| Asset / boundary | Likely failure | Business impact | Crypto control to pressure-test |
|---|---|---|---|
| Withdrawal signing key | Theft or coercive misuse | Direct fund loss | HSM policy, MPC threshold, dual control |
| Customer archive encryption | Future break of public-key wrap | Mass PII exposure years later | Crypto-agile re-wrap, PQC planning |
| Partner mTLS | Downgrade or cert mismanagement | Fraudulent instructions accepted | Suite allowlists, pinning policy, monitoring |
| Smart-contract upgrade key | Single-key governance | Protocol takeover | Timelocks, multisig/MPC, transparent process |
| Support tooling | Session hijack into privileged APIs | Account takeover at scale | Short-lived creds, step-up auth, audit trails |
A lightweight method that teams actually finish
You do not need a 40-page tome. You need a workshop that produces decisions.
Step 1 — Draw trust boundaries
Separate internet clients, edge APIs, core ledgers or payment rails, custody/key services, analytics/AI layers, and third parties. For AI features that touch ledger or payment data, keep the probabilistic layer off the authoritative path—see AI and on-chain data boundaries.
Step 2 — Ask four questions per boundary
- What can an attacker read?
- What can they forge or alter?
- What can they replay?
- What happens if this component is unavailable for an hour?
Step 3 — Rank by financial blast radius
Score impact × likelihood × time-to-detect. Anything that moves money or unlocks long-lived archives rises even if likelihood feels “low.”
Step 4 — Tie every high item to a rotation story
If ECDSA on a given curve becomes untrusted tomorrow, how do you revoke, re-issue, and dual-verify? If the answer is “rebuild the service,” you found a crypto-agility debt. That debt is the bridge to key management with HSMs and MPC and post-quantum migration.
Compliance is an input, not the whole model
MiCA’s phased 2024–2025 obligations for crypto-asset service providers raise expectations around custody, disclosures, and operational resilience. Those rules constrain architecture; they do not replace a threat model. Auditors ask whether controls match risks. Attackers ask whether your signing path has one bored human and a laptop.
Product context still matters. If you are still deciding whether a ledger belongs in the product at all, revisit where blockchain makes business sense before you threat-model a chain you do not need.
What “good” looks like after the workshop
- A one-page diagram with named trust boundaries and data lifetimes
- A ranked list of cryptographic assets and owners
- Explicit harvest-now-decrypt-later cases for archives
- Documented rotation paths for the top signing and wrapping keys
- Open questions assigned to engineering, security, and compliance—not parked in a shared drive
Threat modeling is how crypto-agility becomes prioritized work instead of a slogan. Next in the series: choosing custody shapes when keys are the product.
