Key Management & Operational Security for Crypto Payments

Most of the major incidents of 2025-2026 ultimately trace back to keys or signing — a compromised signing tool, a leaked admin key, or a phished operator. (We break those cases down separately in our look at recent crypto payment hacks.) The common thread tends to sit somewhere in how keys are authorized, stored, or used to sign.

The problem is that multisig, MPC, hot/cold wallets, and HSM get discussed as if they're options at the same level, and conflating them turns selection into a mess. They're actually three independent dimensions, and a real key-management setup is a combination of all three. This piece works through each one, then covers the hybrid architecture, the signing infrastructure and operational standards that hold it together, and the wider operational surface around it — API and infrastructure isolation, people and vendors, domains and identity, and the newest and least understood risk, AI Agents with access to your funds.

Private Keys, Seed Phrases, and Why "It's on My Device" Isn't Security

At the core of all of this is the private key: a string of cryptographic random numbers. Whoever holds it can sign transactions and move the funds at the corresponding address. It's the ultimate control over an address's funds — and the ultimate single point of risk.

A seed phrase (usually 12 or 24 words, the BIP-39 standard) is a human-readable encoding of that private key. The "Hierarchical Deterministic" (HD) rule derives thousands of private keys and addresses from one seed phrase. That makes a seed phrase at least as sensitive as a single private key, arguably more so: leak one private key and you lose one address; leak the seed phrase and you lose the entire wallet.

Here's a common misconception worth naming directly: some assume that as long as the signing device and wallet are in your own hands, and the key is offline, nothing can go wrong. The problem is that private keys and seed phrases in ordinary software and hardware wallets can be exported. Anyone with internal access to the device or a backup can export and copy the private key, then control the funds from anywhere — without ever touching that "own" device.

So "the key is on my own device" doesn't equal "no one else can take it." What actually matters is whether the private key can be exported. As you'll see below, HSM is the only option that blocks export at the hardware level.

Three Independent Dimensions, Not One Spectrum

Before you can pick a setup, it helps to separate the three questions you're actually answering.

Authorization Model: Single-Sig, Multisig, or MPC/TSS

Single-sig means one private key controls everything — the simplest setup, and the biggest single point of failure.

Multisig requires M of N independent private keys to sign together (e.g., 3-of-5), with each signer holding a complete, independent private key. On chains that support smart contracts, contract multisig (Safe is the de facto standard) implements this logic in a contract, with signatures and threshold rules publicly verifiable on-chain — at the cost of higher gas per transaction, and a contract-configuration edit every time you change signers. There's an easily overlooked weakness here too: the signing infrastructure for contract multisig is still immature. A Safe execTransaction call often shows up on a hardware wallet as a long string of calldata, so signers struggle to see what they're actually approving, and ecosystem support for Clear Signing and transaction parsing is still limited. This is exactly the attack surface exploited in the Bybit incident, which is why companies adopting contract multisig often need to bring in third-party transaction parsing and cross-verification to fill the gap. Chains like Bitcoin, by contrast, support multisig natively at the script layer, with no contract dependency.

MPC (threshold signatures, TSS) is not "cutting one complete private key into pieces." Real MPC uses distributed key generation (DKG): the key is distributed from the moment it's created, each party holds an independent key share, and no complete private key ever exists at any point. Each party computes a partial signature from its share, and those partial signatures are combined by a cryptographic protocol into one standard signature — a computation, not a concatenation of byte strings — so the result is indistinguishable on-chain from an ordinary single signature. Gas cost is normal, cross-chain compatibility is good, and changing signers or the threshold doesn't require touching a contract.

It's worth distinguishing MPC/TSS from an older, easily confused method: Shamir Secret Sharing (SSS). SSS cuts an already existing complete private key into n pieces; to sign, enough pieces are gathered and the complete private key is reconstructed in memory before signing — and that moment of reconstruction is the single point of failure. TSS never reconstructs; the complete private key never appears. That's what makes it more secure than SSS.

Both multisig and MPC remove single-point risk, just through different mechanisms. Multisig is multiple complete keys plus on-chain verification: transparent, but costly and cumbersome to rotate signers. MPC is multiple key shares plus off-chain combination of partial signatures: flexible and cheap, but coordination depends on your infrastructure.

Hardware Protection: Software, Hardware Wallet, TEE, or HSM

Software storage keeps the private key in a server or software — the most convenient option, and the most fragile. A hardware wallet (Ledger, Trezor, and similar) keeps the key in a secure chip, signs inside the device, and never lets the key leave.

TEE (Trusted Execution Environment) — think Intel SGX, AWS Nitro, or Apple Secure Enclave — carves out an isolated, encrypted memory region on a general-purpose CPU, where keys and signing computation stay out of reach even of an attacker with OS root. It sits between software and HSM: strong logical isolation, good performance, and able to run arbitrary code (including MPC protocols), though its physical tamper resistance and compliance certification fall short of HSM. This is also the most common way to store MPC key shares — generated by DKG inside the enclave and never removed from it. Fireblocks, for example, spreads MPC key shares across SGX enclaves in multiple clouds.

HSM (Hardware Security Module) is enterprise-grade tamper-resistant hardware meeting certifications like FIPS 140-2/3, with physical tamper resistance and automatic wipe on intrusion. Its strongest guarantee: the private key is generated inside the hardware, marked non-exportable, and physically cannot leave. That's what fundamentally separates it from software and hardware wallets, and it's why HSM suits custody of high-value complete private keys.

This dimension is orthogonal to the authorization model above: each complete key in a multisig can live in a hardware wallet or an HSM, while each MPC share usually lives in a TEE enclave.

Fund Temperature: Hot, Warm, or Cold

This dimension doesn't care how the key is stored — only how exposed the private key is to the internet, meaning how fast and how automatically the money can move.

Hot wallets are always online, used for instant payments and automated payouts — fastest and highest-risk, usually holding only a single-digit percent of total funds. Warm wallets are online, but with the private key isolated in a protected environment (a dedicated signing service or HSM), requiring a human in the signing loop; these handle day-to-day operational settlement. Cold wallets are fully offline and air-gapped, used for long-term storage of large reserves — highest security, slowest to use, and usually holding most of the funds.

To be clear, temperature is fundamentally about the private key's online exposure and how readily funds move; transfer frequency and share of funds are consequences of that, not the definition. This dimension is likewise orthogonal to the first two: a cold wallet can use multisig plus HSM, and a hot wallet can use MPC.

Put the three together and you get the full picture: authorization model, hardware protection, and fund temperature are independent, and a real key-management setup combines all three.

Common Key-Management Setups

Here's how the industry commonly combines the three dimensions:

The point of selection is to tier by fund temperature and use the best combination at each tier. Hot wallets need speed, so prefer MPC. Cold wallets need stability and auditability, so prefer multisig plus HSM. Governance and contract privileges need transparency and accountability, so prefer contract multisig plus timelock.

BlockSec's Recommended Hybrid Architecture

BlockSec recommends a hybrid architecture tiered by temperature.

Hot/warm wallets: MPC signing. It removes the single point of failure of a private key, keeps signing latency low, and suits high-frequency payments. Shares should be spread across different physical locations and security domains.

Cold wallets: multi-party control plus on-chain auditability, suited to large reserves. Which implementation to use depends on your team's on-chain operational capability — there are two paths:

• For maximum transparency, with mature on-chain operations: use contract multisig (e.g., Safe's 3-of-5), where threshold rules and every signature are publicly verifiable on-chain. On Bitcoin, use script-layer native multisig, with each signer protecting their own key in an HSM or hardware wallet. Note that signature-parsing tooling for contract multisig is still immature, so the team has to add cross-verification itself — operations here aren't light.
• For teams less fluent in on-chain execution who want less operational complexity: use MPC threshold signing with shares in a TEE, then bring in an independent third party as a co-signer to run a transaction safety check before each signature. This avoids the contract-multisig tooling gap and builds independent third-party verification directly into the signing threshold.

Contract upgrades and policy changes: multisig plus timelock. Any privilege-changing operation requires multi-person approval and a time delay.

A few parameters matter regardless of which path you take. Use at least 3 signers, with a threshold of at least 50% but below the total count — avoid N-of-N, since a single unreachable signer would block signing and lock funds, and if every signer is indispensable, each becomes a critical target for coercion or kidnapping. A threshold below the total leaves redundancy and lowers the value of targeting any one signer. Each signer should also use a brand-new, dedicated address in each multisig, never shared with other multisigs or personal wallets, and signers should be diverse in geography, organizational role, and legal entity — with dispersion rising as the wallet's risk level rises.

That risk level should come from a formal grading: rate each wallet by its financial impact on the business, protocol dependency, and reputational risk, and map each grade to a different threshold, approval flow, and monitoring density. Review the grading every 6 months, and immediately after a large TVL change, a contract upgrade, or a security incident.

Blind Signing and Signing-Environment Isolation

Blind signing means your signing tool shows you a calldata hash — not what the transaction actually does. It's not a hypothetical risk: at signing time the signer can't understand the real meaning of a transaction from the interface, and that gap was one direct cause of the Bybit incident, where the front end or back end used for signing was compromised and signers approved a malicious transaction without any bug in the contracts themselves.

Locking down the three dimensions above only holds if the signing process around them is just as hardened. A few standards apply regardless of setup:

• Mandatory signing hardware. All production multisig operations should use a hardware wallet with a screen large enough to display the full transaction summary and support Clear Signing, PIN protection with firmware integrity verification, and a supply chain limited to the manufacturer or authorized resellers — verify authenticity on receipt.
• Physically isolated signing environment. Signing should run on air-gapped devices, not sharing the everyday office network; high-value operations warrant dedicated signing devices. Deploy the signing service in an independent security domain, physically isolated from business logic and the front end. Signing nodes shouldn't be directly exposed to the public internet — connect to them only via VPN or a private line. Signing operation logs should be stored separately, unmodifiable by the business system.
• Independent transaction verification. Verify transaction content through an independent channel before signing — a dedicated terminal, a hardware device, or a third-party transaction-simulation/risk service. This check is best done by an independent third party, not just your own front end or back end — trusting only internal systems is itself a single point of failure. Once the internal front end or back end is compromised, as with Bybit, what the signer sees on-screen is tampered fake information, and verifying yourself against yourself is no verification at all. The payout path especially needs this independent line of defense.
• Clear Signing and cross-verification. Use tools that parse transaction semantics, so the signer sees "transfer 1,000 USDC to 0x1234..." instead of a string of calldata, and cross-verify key parameters — chain ID, target address, calldata, value, nonce, and operation type — as identical across at least two independent tools or interfaces.
• Human plus automated dual check. An automated rules engine handles first-pass screening, and a human confirms large transactions before they go out.
• Zero trust and backups. Deploy the signing service, business logic, and front-end interface in different security domains, and keep fallbacks for the primary signing UI, RPC, and block explorer, so a single vendor or service failure can't block emergency signing.

Multisig Operational Standards

Key and threshold choices only get you so far. A few operational standards matter just as much.

Multisig registry. Keep a single record of every multisig, with each entry including at least: address, chain, signing threshold, risk grade, purpose, signer addresses, contracts controlled, on-chain roles, and last review date. Security-sensitive changes should update the registry within 24 hours, routine changes within 3 days.

Signer lifecycle management. Verify addresses before onboarding by having the prospective address sign a specific message, checked with an independent tool. Set SLAs for removing a departing or removed signer's privileges by risk grade — urgent within 48-72 hours, critical within 7 days, everything else within 14 days. Run a quarterly access review to confirm each signer still controls their key, and refresh signer training at least annually, covering transaction verification, emergency procedures, and social-engineering/phishing defense, with a hands-on assessment after.

Seed phrase and backup protection. No digital storage of any kind — no cloud drives, photo albums, or documents. Store backups dispersed across different geographic locations, recoverable against natural disaster, theft, and an operator going missing. No single point should hold the complete recovery information.

Secure communications. Coordinate among signers using primary and backup channels on different platforms, each enforcing MFA, end-to-end encryption, and invite-only membership. Before signing, verify a signer's identity through an independent channel — a video call, a passphrase, and an authenticated second channel — to prevent a hijacked IM account from impersonating a signer.

Emergency response SLA. Set signer response times by incident severity, for example urgent under 2 hours, time-sensitive 2-12 hours, routine 24-48 hours. Test signer reachability quarterly, not just on paper, and run at least one end-to-end emergency drill a year, covering scenarios like a leaked key, an unreachable signer, a compromised communication channel, and emergency protocol operations.

Multisig on-chain monitoring. Monitor signer/threshold changes, over-threshold transfers, nonce gaps, unknown-address interactions, failed transactions, Module/Guard changes, and abnormal proposer wallet balances. The monitoring infrastructure itself needs to be tamper-resistant.

API Security

API security is the first line of defense for your payment backend. That means authentication through an API key plus HMAC signature or FIDO2/WebAuthn, rate limiting to prevent brute force and abuse, DDoS protection via a CDN/WAF service, strict validation of every input parameter to prevent injection, and log auditing so every API call produces a complete audit trail.

Signing environments need to be isolated from all of that, not just protected by it — which is why the signing service belongs in its own security domain, as covered above.

Operations Security: People, Vendors, and Independent Audits

Several major incidents in 2026 involved social engineering — fake recruiting, IT-support impersonation, and AI face-swapping among them. Defending against it takes three levels working together.

Training and assessment comes first: everyone with access to signing systems, production credentials, or sensitive operations completes security training at onboarding, refreshes it annually, and updates the content within 30 days of any process change.

Separation of duties matters just as much: initiation, approval, and execution can't be done by the same person, and admin accounts can't pay out directly. High-sensitivity operations like signing should use dedicated devices — full-disk encrypted, auto-locking — with hardware wallets kept in a safe when not in use, and all remote access routed through a VPN.

Third parties need the same discipline. Do due diligence before selecting a vendor, re-review key vendors' compliance and security status annually, and grant third-party access a clear scope, purpose, and expiry — revoked immediately once that expires or the project ends. Verify third-party personnel identity independently before granting any access.

None of this should rely on internal self-checks alone. Run independent third-party security assessments regularly, covering at least penetration testing, red-team exercises, and code and smart-contract audits. Fix findings one by one and verify closure in the next assessment round.

Development and Infrastructure Security

Several major payment and crypto incidents in recent years trace back to a compromised development process — with the contracts and signing logic themselves perfectly fine. That means the development and infrastructure layer deserves the same attention as the signing layer, across four areas.

Development-environment isolation keeps development accounts separate from privileged accounts (signing, cloud management), keeps production credentials out of reach of the development environment, and puts development tools and extensions on an approval list.

Your code repos and supply chain need branch protection, signed commits, and multi-person review on the main branch. Pull dependencies only from official repos with pinned versions and typosquatting checks, and run automatic secret scanning that revokes and rotates any exposed key immediately.

In CI/CD, pipeline configuration changes need multi-party approval and version control, with reproducible builds. Secrets go through a dedicated manager like Vault or a cloud KMS — production secrets should never be directly accessible to humans — and SAST plus dependency scanning are preconditions for deployment, not optional extras.

For infrastructure and cloud, grant privileged access via just-in-time provisioning, multi-party approval, and time limits. Keep break-glass accounts for emergencies, but alert on every use. Run complete audit logs, real-time alerts on admin operations, and regularly drilled backup and disaster recovery.

Domain, DNS, and Identity: The Underrated Attack Surface

Domain and DNS are a badly underrated attack surface in crypto — many phishing incidents and thefts trace back to a compromised registrar account or hijacked DNS. Protecting the domains where users initiate fund operations matters as much as protecting the signing environment itself.

Manage your registrar account as a high-privilege account: enforce hardware-key MFA, and require out-of-band second confirmation for critical changes like transfers, deletions, or nameserver changes. On the DNS and email side, enable DNSSEC on critical domains, use CAA to limit which CAs can issue certificates, and configure SPF/DKIM/DMARC (p=reject) on all sending domains — set non-sending domains to explicitly reject mail too, to prevent spoofing.

Monitor continuously for DNS record changes, nameserver delegation, and anomalous Certificate Transparency log issuance, using monitoring infrastructure that doesn't depend on the domain it's watching. Document your handling process for domain hijacking and unauthorized transfer, drill it annually, and set tiered expiry warnings plus auto-renewal so a lapsed domain doesn't become an entry point.

Identity and accounts are the entry point for nearly all lateral movement. A complete inventory of organizational accounts, plus a strict MFA standard, matters more than any single-point defense.

Start with an account inventory: register every organizational account — social media, email, SSO/IdP, registrar, custody platforms, code repos, cloud root, key SaaS — with a clear owner, and review them regularly. Enforce phishing-resistant MFA with FIDO2/WebAuthn hardware keys on high-privilege accounts, and never rely on SMS or voice as the primary factor — SIM swap, SS7, and voice phishing all bypass them. This is the single most effective defense against account takeover.

Enforce a password manager with unique strong passwords, prohibit shared logins, and restrict recovery email and phone to the organizational domain — keep recovery codes in secure storage, not personal email or the cloud. When someone leaves, revoke all their access within 24 hours and rotate any shared credentials they touched, and keep running behavioral and credential-leak monitoring on high-privilege accounts the whole time they're active.

Why an AI Agent's Architecture Is Unsafe by Design

Payment companies increasingly use AI tools and Agents to boost development and operational efficiency — but that opens a new attack surface that, handled poorly, directly threatens funds.

Here's the part that's easy to miss: an AI Agent isn't just a model that answers questions. It's a machine that can read external content, call tools, hold credentials, and execute actions. The root of the risk is that it treats text read from untrusted content as instructions to execute.

That means an attacker needs no vulnerability and no stolen account. Hiding a single sentence in a document, a web page, a code comment, or a PR description can hijack the Agent's behavior into leaking data or performing unauthorized actions. This is called prompt injection, and by 2026 it's been shown to escalate directly to remote code execution — Microsoft demonstrated a single prompt launching a program on the machine running an Agent, and GitHub Copilot, Cursor, and MCP infrastructure have each disclosed RCE vulnerabilities rated CVSS 9.6 or higher.

It gets worse for anything privileged. A development or operations Agent inherits its operator's file access, shell privileges, and database keys by default. A 2026 study covering mainstream coding Agents found that all of them could be broken by prompt injection, with an adaptive attack success rate above 85%. Any Agent that processes untrusted input should be treated as a potential insider holding your credentials — and the supply chain is a high-risk link too: in March 2026, a poisoned AI-gateway dependency sat on a public repo for 3 hours and was downloaded nearly 47,000 times.

How to Get AI Agent Efficiency Without Losing Control of Funds

The approach is to put the Agent under the same constraints you'd apply to untrusted code, across five controls:

• Isolated execution — run the Agent's tool execution in a sandbox, so prompt injection can't reach the real shell, production keys, or the signing environment.
• Least privilege — grant the Agent's tools, database keys, and MCP services only the minimum needed for a single operation, never a "full-access" credential.
• A human gate on fund operations — for anything involving transfers, signing, or privilege changes, the Agent can only propose, never execute automatically. Independent human approval applies here too, the same principle behind the signing verification covered above.
• Separate trusted instructions from untrusted data — do this at the architecture level, and don't expect the model to "tell them apart on its own."
• Supply-chain locking — apply the same version pinning and provenance checks to AI-related dependencies that you apply to your regular code repos.

These constraints don't have to stay theoretical. BlockSec's open-source Web3 Companion is a reference implementation of a secure agentic wallet (MIT license, research preview). It lets an AI Agent help a user prepare on-chain transactions while keeping private keys and final authorization entirely out of the Agent's reach. Its threat model treats the Agent itself as untrusted — the whole system has to guarantee that even a fully compromised Agent can't move the user's funds.

The architecture rests on three points. Key isolation means only one independent signing module (a separate Go process) can ever touch the private key — the Agent gets a transaction-intent ID, can request a signature, but never sees a key. Keys are stored with envelope encryption (AWS KMS or local AES-256), and plaintext exists in memory only for the instant of signing, then is zeroed.

Before broadcast, a transaction passes through four layers in sequence, each assuming the one before it failed: transaction simulation (decoding calldata, predicting reverts), counterparty risk scoring, pure-Go hard-policy limits (per-transaction cap, daily budget, whitelist — none of which the Agent can modify), and finally passkey human confirmation, a WebAuthn fingerprint or face scan that a software-only attack can't forge. Key, policy, and passkey form three independent trust boundaries, so breaching one leaves the other two intact.

An AI Agent can genuinely boost efficiency, but it must not have sole control over funds and signing. Put it in a least-privilege sandbox as an assistant, and let humans make the final call on funds and signing.

Putting It Together

Key management isn't one decision — it's three, made independently and then combined: who has to sign, where the key or share physically lives, and how exposed it is to the internet. Getting the combination right for each fund tier, backing it with hardened signing infrastructure, and holding it together with the operational standards above is how BlockSec frames closing the gaps behind most of 2025-2026's key- and signing-related incidents. And because the surface now extends past keys — to APIs, people, vendors, code pipelines, domains, identity, and AI Agents — each of those needs the same treatment: assume the layer before it failed, and keep a human in the loop wherever funds can move.

For the full picture of where key management and operational security fit alongside the rest of a payment system's compliance program, download our crypto payment security and compliance playbook (PDF).

FAQ

What's the actual difference between MPC and multisig? Multisig is multiple complete private keys, each verified separately on-chain — transparent, but costly and cumbersome to rotate signers. MPC (threshold signatures) is multiple key shares generated so no complete private key ever exists; partial signatures are combined off-chain into one signature — flexible and cheap, but dependent on your coordination infrastructure.

Is Shamir Secret Sharing (SSS) the same as MPC? No. SSS splits an already-existing complete private key into pieces and reconstructs the full key in memory to sign, which makes the reconstruction moment a single point of failure. Real MPC (TSS) never reconstructs a complete private key at all — each party only ever computes a partial signature from its own share.

What's the difference between a TEE and an HSM? A TEE (like Intel SGX, AWS Nitro, or Apple Secure Enclave) is an isolated, encrypted region on a general-purpose CPU that can run arbitrary code, including MPC protocols — strong logical isolation, but weaker physical tamper resistance and certification than an HSM. An HSM is dedicated tamper-resistant hardware where the private key is generated inside, marked non-exportable, and physically cannot leave.

What is a warm wallet, and how is it different from hot or cold? A warm wallet is online but keeps the private key isolated in a protected environment (a dedicated signing service or HSM) and requires a human in the signing loop, used for day-to-day settlement — sitting between an always-online, automated hot wallet and a fully offline, air-gapped cold wallet.

What does BlockSec recommend for cold storage specifically? It depends on the team's on-chain operational capability: teams with mature on-chain operations can use contract multisig (e.g., Safe's 3-of-5) with each signer's key in an HSM or hardware wallet; teams that want less operational complexity can use MPC threshold signing with shares in a TEE plus an independent third-party co-signer for transaction safety checks.

What is blind signing, and why is it dangerous? Blind signing is when a signing interface only shows a calldata hash instead of what the transaction actually does. The signer can't verify the real meaning of what they're approving, which was one direct cause of the Bybit incident.

Can AI Agents be trusted with crypto payment operations? Not with sole control. An AI Agent should only be allowed to propose fund operations, never execute them automatically — transfers, signing, and privilege changes all need independent human approval, with the Agent running in a least-privilege sandbox.

What is prompt injection, and how serious is it? Prompt injection hides instructions in untrusted content — a document, web page, code comment, or PR description — that hijacks an AI Agent's behavior. By 2026 it has escalated to remote code execution in disclosed vulnerabilities affecting mainstream coding tools, rated CVSS 9.6 or higher.

What's the single most effective defense against account takeover? Phishing-resistant MFA — enforcing FIDO2/WebAuthn hardware keys on high-privilege accounts and never relying on SMS or voice as the primary factor, since SIM swap, SS7, and voice phishing can all bypass those channels.