TL;DR: Billions were lost across hot wallets, cold wallets, admin keys, bridges, and DeFi protocols in Anjuna's review of 2024 through H1 2026 blockchain incidents, with attackers increasingly exploiting trust, social engineering, and compromised infrastructure rather than only smart-contract bugs. TEEs help protect key usage, but they do not replace contract review, decentralized verification, or transaction-intent controls.
At a glance
What this is: Anjuna's analysis argues that blockchain theft still concentrates on key handling and trust boundaries, with TEEs mitigating key exposure but not broader governance or signing failures.
Why it matters: IAM and NHI practitioners should read this as a reminder that key custody, signing approval, and delegated trust are governance problems, not just crypto problems, especially where machine-held signing authority overlaps with human decision points.
Context
Blockchain key security is the governance problem that keeps resurfacing in exchanges, wallets, bridges, and DeFi protocols. When a signing key, a verifier, or the human process around approval is compromised, the architecture usually fails at the trust boundary rather than at the cryptography itself. That makes this a relevant identity and NHI topic because signing keys, admin keys, and verifier services behave like high-risk non-human identities with delegated authority.
The article frames Trusted Execution Environments as a containment control for key material, not a complete security model. That distinction matters for practitioners because the same incident pattern can involve server compromise, insider misuse, social engineering, or forged transaction intent. The underlying lesson is that key protection, governance, and verification all need to align, and the article's starting position is typical of the current market.
Anjuna's review of 2024 through H1 2026 blockchain incidents shows billions lost across hot wallets, cold wallets, admin keys, bridges, and DeFi protocols, with attackers increasingly exploiting trust, social engineering, and compromised infrastructure rather than only smart-contract bugs. TEEs help protect key usage, but they do not replace contract review, decentralized verification, or transaction-intent controls.
Key questions
Q: What breaks when blockchain signing keys are handled like ordinary credentials?
A: The failure is usually not the key itself, but the trust chain around it. If signing authority sits in always-on infrastructure, a compromised server, a deceived signer, or a manipulated approval workflow can turn a valid credential into an irreversible asset transfer. That is why key custody must be governed as privileged authority, not storage.
Q: Why do hot wallets and admin keys create outsized loss risk?
A: They concentrate authority in keys that can move funds, mint assets, or change contract behaviour. Once an attacker reaches that authority, the blast radius is immediate because the compromise bypasses normal application checks and turns signing into execution. The risk is highest when the same key can act without quorum, delay, or transaction review.
Q: What are the warning signs that transaction verification is failing?
A: Look for mismatches between approved intent and on-chain action, unusual zero-timelock changes, signer confusion, repeated emergency approvals, or bridge messages that depend on a single trusted verifier. Those signals show that the governance layer is weaker than the signing layer and that attackers may be targeting approval, not encryption.
Q: Should organisations treat TEE-based key protection as enough on its own?
A: No. A TEE can reduce exposure of the key material, but it cannot prove that a transaction is legitimate, decentralize a bridge, or stop a human from approving a malicious action. Security teams still need quorum controls, verification of transaction intent, and governance over who can exercise signing authority.
Technical breakdown
Why hot wallet compromise keeps recurring
Hot wallets expose signing keys to always-on infrastructure, which means the server, orchestration layer, or operator workflow can become the failure point even when the cryptography is sound. In practice, attackers do not need to break the wallet architecture if they can reach the key, the signing process, or the transaction approval path. TEEs reduce that exposure by keeping key material and signing operations inside isolated hardware-backed execution, but they do not fix bad authorization logic or weak operational controls.
Practical implication: Treat hot wallet protection as an identity-bound signing problem and isolate key operations inside hardware-backed enclaves.
Cold wallet and multisig trust can still be subverted
Cold storage reduces exposure, but it does not eliminate the risk of manipulated signing intent. If users approve a malicious transaction, if multisig signers are socially engineered, or if the interface shown to the signer diverges from the on-chain action, the wallet can still be drained. This is where transaction verification becomes as important as key custody: the control must confirm what is being signed, not just who signed it. TEEs can protect the signing workflow, but they cannot validate human judgment or contract semantics on their own.
Practical implication: Add transaction-intent verification and signer validation around multisig and cold-wallet approval flows.
Admin keys behave like privileged non-human identities
Admin and minting keys can create, upgrade, or reconfigure financial systems, so they function like privileged machine identities with unusually broad authority. If those keys sit in cloud KMS, are used without quorum controls, or can be exercised without time delays and transparency, the blast radius is much larger than a standard wallet compromise. A TEE can harden key custody, but governance still decides whether a single compromised operator or workflow can trigger irreversible actions.
Practical implication: Apply privileged-access governance to admin keys with quorum, delay, and transparent approval controls.
Threat narrative
Attacker objective: The attacker aims to turn trust in signing authority into direct asset theft, unauthorized minting, or protocol compromise.
- Entry begins when attackers compromise a hot wallet server, manipulate a signing interface, or socially engineer staff and signers into trusting malicious transaction flow.
- Credential access occurs when the attacker reaches a private key, minting key, verifier node, or privileged approval path that can authorise transfers or upgrades.
- Escalation follows when that trust is used to drain wallets, mint unbacked assets, alter contract logic, or approve forged cross-chain messages.
- Impact is theft, depegging, or protocol loss at scale, with the attacker converting delegated signing authority into irreversible value extraction.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
- BitMart hot wallet hack 2021: A stolen private key let an attacker drain two BitMart hot wallets on Ethereum and Binance Smart Chain of about $150 million in December 2021.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Privileged signing keys are non-human identities with governance debt. The article shows that wallets, minting keys, and bridge verifiers fail when they are treated as technical assets rather than governed authorities. Once a key can move value, mint assets, or approve message flow, it needs lifecycle controls, scoped authority, and accountability just like any other privileged identity. Practitioners should stop thinking about custody alone and start governing signing power.
Trust-boundary attacks are now as important as direct key theft. The shift described in the article is from breaking the wallet to manipulating the people, infrastructure, or verifier model around it. That means security teams need to model the entire signing chain, not just the private key store. The practical lesson is to measure whether approval, verification, and execution still agree when the environment is compromised.
TEE adoption does not remove the need for transaction governance. Confidential computing can reduce exposure of key material, but it cannot validate whether a transaction is legitimate, whether a signer was deceived, or whether a contract change should be allowed. That makes TEE controls necessary but incomplete. The field should view secure enclaves as containment for NHI-like signing authority, not as a substitute for policy.
Cross-chain trust models deserve the same scrutiny as credential stores. A one-verifier bridge is structurally similar to a single shared secret: both create a concentrated point of failure. The article makes clear that decentralization is not only a blockchain design preference but an access-governance requirement. Practitioners should treat verifier quorum and message validation as core trust controls.
Key security is converging with agentic decision governance. The more signing paths are delegated, automated, or hidden behind abstractions, the more the real security question becomes who is allowed to decide and under what constraints. That is an identity problem as much as a cryptographic one. Organisations should govern transaction authority, not just protect key material.
What this signals
Privileged signing authority now behaves like a machine identity programme, not a storage problem. For readers running wallets, custodial systems, or bridge services, the real issue is whether the right entity is allowed to sign the right action under the right constraints. That means governance has to cover issuance, approval, and revocation of signing power, not just where keys reside.
Trust-boundary failures are becoming the dominant attack path in crypto infrastructure. The article's incident set shows that social engineering, verifier abuse, and UI manipulation can matter more than classic key theft. For practitioners, that means transaction review, sign-off policy, and delegated authority need the same scrutiny usually reserved for privileged human access.
Transaction-intent control is the control gap most teams still underbuild. The ability to verify what a user or service is actually authorizing is now central to preventing misuse of high-value signing paths. Teams should expect attackers to continue targeting approval workflows, because those workflows often remain the weakest link between cryptography and execution.
For practitioners
- Isolate signing operations inside hardware-backed enclaves Move hot wallet, minting, and verifier signing out of general-purpose infrastructure so the private key is never exposed in the clear, even if the host is breached.
- Require transaction-intent verification Compare what the signer sees in the UI with what the contract or bridge will actually execute, especially for multisig approvals and cross-chain messages.
- Add quorum and delay to privileged key actions Make upgrades, minting, and other admin operations require multiple independent approvals and time-bound review before execution.
- Remove single-verifier trust from bridge workflows Design cross-chain message verification so no single node or operator can authorise a transfer on its own.
- Audit signer workflows for social engineering exposure Review how staff, approvers, and custodial partners can be tricked into approving malicious activity, then harden those approval paths with separate checks.
Key takeaways
- The recurring failure mode is not just exposed keys, but poorly governed signing authority that can be manipulated through servers, signers, or trust workflows.
- The article links recent losses to both direct key compromise and attacks on transaction intent, verifier trust, and approval processes.
- TEE-based containment helps reduce key exposure, but it only limits one part of the problem unless paired with quorum, verification, and privileged-access governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Signing and minting keys in this article hold broad authority over assets and upgrades. |
| NHI-07 — Long-Lived Secrets | The incidents centre on keys that remain usable long enough to be stolen or abused. | |
| NHI-10 — Human Use of NHI | Several incidents relied on people approving or misusing machine signing authority. | |
| Recommendation — Limit signing keys to the minimum authority needed and separate minting, upgrade, and transfer roles. Shorten the usable life of signing secrets and rotate any key exposed to shared infrastructure. Separate human approval from machine signing and enforce clear review of transaction intent. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article describes attackers reaching keys or trust paths and then converting that access into asset theft. |
| Recommendation — Map wallet, verifier, and admin-key abuse to credential access and impact when prioritising detections. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Private keys and minting keys function as authenticators that need lifecycle control. |
| Recommendation — Apply authenticator lifecycle controls to issue, rotate, revoke, and protect signing credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The trust failures described are access-governance failures over privileged signing paths. |
| Recommendation — Review entitlements on signing systems so no single compromised account can authorise high-value actions. | ||
Key terms
- Trusted Execution Environment: A Trusted Execution Environment is a protected hardware-backed area where code runs with stronger isolation from the host system. In AI inference, the point is not just secrecy in transit, but limiting what operators, hypervisors, and surrounding infrastructure can observe during processing.
- Transaction Intent: The decoded business action that a system is actually about to perform, such as a payment, trade, or signing event. For autonomous agents, intent is the object that must be authorised, because the agent's stated goal may differ from the executable transaction.
- Privileged Signing Authority: Privileged signing authority is the power to approve high-impact actions such as transfers, minting, upgrades, or cross-chain messages. It behaves like a high-risk non-human identity because the security issue is not storage alone, but who can exercise the authority and under what constraints.
- Cross-Chain Trust Model: A cross-chain trust model defines how one chain or system decides that a message, transfer, or state change from another chain is valid. Weak models collapse when a single verifier, relay, or approval path becomes a single point of failure.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity teams apply governance discipline to high-risk signing authority and other privileged non-human identities.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org