Cross-chain bridge security: Signer keys, validator risk and lessons from bridge thefts

A cross-chain bridge holds pooled assets on one chain and releases them on another whenever its verification logic says so, which makes the signer keys, validators and message-verification code behind it one of the most valuable targets in Web3. The largest bridge thefts have not needed new cryptography: they used phished staff, signing permissions that were never revoked, and contract changes that made forged messages look valid. This guide covers how bridge trust models translate into operational risk, how to run signer and validator keys as non-human identities, the controls that limit loss when verification fails, monitoring and response, and how to assess a bridge before you integrate or hold assets on it. It is written for bridge operators, protocol security teams, exchanges and treasuries that use bridges, and fraud teams tracking stolen funds. It builds on the bridge section of the Blockchain and Distributed Ledger Security Guide.

Key takeaways

• A trusted bridge is only as strong as the independence of its signers. At Ronin, five of nine validator signatures were enough, and four of the keys sat with one organisation.
• Signer and relayer keys are non-human identities. They need an owner, isolated custody, scoped delegation and a revocation path, like any privileged machine credential.
• Revoke temporary signing delegations. Ronin's attacker used an allowlist arrangement that had been discontinued but never revoked.
• Treat upgrades and initialisation as security events. Nomad's loss came from a production upgrade that let unproven messages pass verification.
• Assume verification will fail one day, and cap the damage. Rate limits, delays on large withdrawals, outflow monitoring and a tested pause turn a total loss into a bounded one.

How bridge trust models translate into operational risk

ethereum.org groups bridges into native bridges, validator or oracle based bridges, generalised message passing bridges and liquidity networks, and distinguishes trusted bridges, which are externally verified by multisig federations, multi-party computation or oracle networks, from trustless bridges that rely on the connected chains' own validators. It lists smart contract risk, systemic financial risk from wrapped assets and counterparty risk as the main hazards. The design decides which operational controls matter most.

See the Smart Contract Upgradeability and Proxy Security Guide and the Smart Contract Access Control Guide for the contract side.

Lessons from official incident reports

Ronin bridge, March 2022

Sky Mavis's post-mortem states that Ronin had nine validators and the attacker controlled five keys: four Sky Mavis keys and one Axie DAO validator. A former Sky Mavis employee was compromised through spear phishing, which gave access to Sky Mavis IT systems and the validator nodes. The Axie DAO signature came through a gas-free RPC node: Axie DAO had allowlisted Sky Mavis to sign on its behalf in November 2021, the arrangement was discontinued in December 2021, but the access was never revoked. The attacker drained 173,600 ETH and 25.5 million USDC in two transactions on 23 March 2022, and the theft was discovered on 29 March, six days later, which the post-mortem attributes to the lack of monitoring of large bridge outflows. Remediation included increasing the validator count, work-only devices, zero trust architecture and blocking withdrawals of that size without human interaction. The FBI subsequently attributed the theft of USD 620 million in Ethereum reported on 29 March to Lazarus Group and APT38, actors associated with North Korea.

Nomad bridge, 2022

Nomad's root cause analysis states that its Replica contract failed to authenticate inbound messages, allowing any message to be forged as long as it had not already been processed. Replicas were initialised with a zero root, unproven messages also default to a zero root, and the acceptance check therefore returned true for them. The vulnerable logic went live in a production upgrade on 21 June 2022; the change had been made during an audit remediation cycle. Nomad notes that its watchers monitored for Updater key compromise, not contract logic bugs, so no alarm fired because no signature was forged.

Signers approving what an interface shows them

Bridge admin and upgrade keys are usually held in a multisig operated through a web interface. In the Bybit Hack, the multisig signers approved what appeared to be a routine transfer because malicious JavaScript had been placed in the wallet provider's hosted code, after a developer's AWS session tokens were hijacked. The same pattern applies to any bridge whose signers trust a single interface.

Running signer and validator keys as non-human identities

Every key that can approve a bridge transfer, relay a message or upgrade a contract is a privileged machine credential. Apply the same lifecycle discipline as for cloud service accounts. See the Non-Human Identity (NHI) Guide and the MPC Wallet and Threshold Signing Security Guide.

• Signer threshold and independence: raising the threshold only helps if the extra signers are genuinely independent organisations with separate infrastructure. Ronin's remediation increased the validator count for this reason.
• Staff targeting: signer operators and engineers are targets for spear phishing, as Ronin showed. Use dedicated signing devices, phishing-resistant MFA and strict separation between personal and signing environments. See the Web3 Developer Operational Security Guide.
• Key ceremonies: generate, back up and rotate signer keys under documented ceremonies with witnesses. See the Cryptographic Key Ceremony Template.

Loss-limiting controls

• Rate limits: cap total outflow per asset per period at a level that keeps a worst-case loss survivable.
• Delays on large withdrawals: hold transfers above a threshold for a defined period, with human review, as Ronin introduced after its theft.
• Pause capability: a pause function controlled by a separate guardian key set, with clear authority to use it and a rehearsed procedure.
• Invariant checks: verify that assets minted or released on the destination never exceed assets locked on the source; alert and pause automatically on breach.
• Upgrade safety: timelocks long enough for independent review, review of initialisation values and default states (the Nomad class of bug), and testing of verification paths with unproven and malformed messages.

Monitoring, detection and response

Nomad's watchers looked only for key compromise, and Ronin had no outflow monitoring. Monitoring must cover both keys and logic.

• Outflow monitoring: alert on withdrawals by size, frequency and destination, and on divergence between locked and minted supply. See the Blockchain Analytics and On-Chain Monitoring Guide.
• Signer behaviour: alert on signatures from unusual infrastructure, at unusual times, or for transactions not raised through the normal workflow.
• Contract events: alert on upgrades, role changes, guardian changes and messages processed without a matching source event.
• Off-chain signals: phishing attempts against signer operators, new devices on signer accounts, changes to hosted interface code.
• Response: pause first, then preserve evidence (transaction hashes, node logs, signer device images), notify law enforcement and analytics providers so stolen funds can be flagged, and communicate with users. See the Web3 Incident Response Playbook.

Metrics that show the controls work:

• Time from an anomalous outflow to alert and to pause, measured in drills.
• Number of active signing delegations past their expiry (target: zero).
• Highest number of signer keys reachable from any single organisation or administrator.
• Share of upgrades that passed through a timelock and independent review.
• Maximum loss possible within the current rate limit window, as a share of total value locked.

Implementation roadmap for operators

1. Map trust: document every key, signer, relayer, guardian and upgrade path, and who operates each one.
2. Remove concentration: move keys so no single organisation, cloud account or administrator can reach a threshold.
3. Clean up delegations: list and revoke every allowlist or signing arrangement that is not current; add expiry to new ones.
4. Add loss limits: deploy rate limits and withdrawal delays on a test network first, then on production with conservative thresholds, keeping the previous configuration ready to restore through the timelocked upgrade path.
5. Monitor: deploy outflow, invariant, signer and contract event monitoring with paging to an on-call team.
6. Drill: rehearse a pause and a key rotation at least twice a year.

Assessing a bridge before you use it

Exchanges, treasuries and protocols integrating a bridge should ask:

• Verification: is it externally verified (which signers or oracles, what threshold) or verified by the connected chains?
• Independence: who operates each signer, and can any one party reach the threshold?
• Upgrades: who can upgrade the contracts, through what timelock, and is upgrade history public?
• Limits: are there rate limits, delays and a pause, and who controls them?
• Monitoring and response: who watches outflows and invariants, and what is the published incident process?
• Exposure: how much of your treasury sits in assets wrapped by this bridge? Wrapped assets carry the bridge's risk even if you never bridge yourself.

Decision guidance

• Trusted versus trust-minimised bridges: externally verified bridges connect more chains quickly and cheaply but concentrate risk in signers; designs verified by the connected chains remove that trust assumption but rely heavily on verification code. Choose by asset value and the operator's evidence of independence and code review.
• Small treasuries: limit bridged holdings, prefer native assets, and set internal limits on exposure per bridge.
• Large operators and exchanges: require signer independence evidence, rate limits and incident commitments in partnership agreements, and monitor exposure continuously.

Common failure patterns

• Concentrated signers: most keys run by one company on one network, as at Ronin.
• Forgotten delegations: a temporary signing arrangement outlives its purpose and becomes the missing signature.
• Logic changes treated as routine: an upgrade alters verification or initial state without targeted review, as at Nomad.
• Watching keys but not logic: monitoring that only fires on unexpected signatures misses forged messages.
• No outflow alarm: a theft is noticed days later by a user rather than by monitoring.
• Single interface for signers: signers trust one hosted web interface, as the Bybit theft showed.

Framework mapping

Practitioner checklist

• Document every signer, relayer, guardian and upgrade key with its operator.
• Confirm no single organisation or administrator can reach the signing threshold.
• Revoke all expired or unused signing delegations and allowlists; add expiry to new ones.
• Hold signer keys in HSM or MPC custody on dedicated devices.
• Require timelock and independent review for every upgrade, including initial values.
• Deploy rate limits, withdrawal delays and a guardian-controlled pause.
• Monitor outflows, locked versus minted supply, and contract role changes.
• Verify transaction content independently of the signing interface.
• Rehearse pause and key rotation at least twice a year.

Standards and references

• ethereum.org: Bridges
• Ronin: Back to Building, Ronin Security Breach Post-mortem
• Nomad: Bridge Hack Root Cause Analysis
• FBI: Statement on Attribution of Malicious Cyber Activity Posed by the DPRK
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Financial Theft

Related NHI Mgmt Group resources: Blockchain and Distributed Ledger Security Guide · MPC Wallet and Threshold Signing Security Guide · Crypto Exchange Identity and Key Security Guide · Web3 Incident Response Playbook