Teams that build their own bridge usually inherit the hardest security and reliability problems themselves. They must solve message validation, source chain finality, failure handling, and upgrade risk without the benefit of mature operational patterns. In practice, that often produces brittle infrastructure, inconsistent trust assumptions, and a larger attack surface than the application team can safely manage.
Why Self-Built Bridges Fail So Often
A bridge is not just a message relay. It is a trust boundary that has to decide which chain events are valid, which are final, and which failures must halt or roll back transfers. Teams that underestimate that complexity usually end up with brittle assumptions around message authenticity, chain reorganisation handling, and upgrade safety.
The hardest part is that each chain has its own consensus rules and failure modes, so a “working” bridge can still be unsafe if it accepts events before they are sufficiently final or if it cannot distinguish a transient fork from a legitimate transfer. That creates both correctness risk and security risk, especially when assets can be moved based on a single bad decision.
When the bridge logic is custom-built, the team also owns every edge case in verification, replay protection, relaying, and recovery. In practice, that means the implementation burden often grows faster than the application team’s ability to test it.
What Breaks in Practice
The most common failure points are message validation, finality assumptions, error handling, and upgrade coordination. If validation is too weak, attackers or faulty relayers may submit messages that look plausible but are not actually authorised by the source chain. If finality is treated too optimistically, a reorg can invalidate an event after the destination chain has already acted on it.
Failure handling is another frequent weak spot. A bridge has to survive delayed relays, duplicated messages, partial outages, and mismatched liveness between chains without minting, releasing, or locking assets incorrectly. Upgrade risk is equally serious, because bridge code often sits in the middle of asset movement and any incompatible change can strand funds or open an unintended execution path.
For teams that want a deeper trust-and-integrity lens, supply-chain controls such as SLSA are useful as a reminder that provenance and verification matter even when the object being secured is bridge software rather than a build artifact. The same principle appears in real-world credential and build compromise patterns like the Nx package attack with more than 2,300 leaked credentials, where trusted software paths were abused to reach sensitive material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Bridge code is custom software that needs secure design, validation, and testing. |
| Recommendation — Apply CIS-16 to secure bridge logic, validation, and release changes before deployment. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Cross-chain value movement depends on preserving integrity and trustworthy transfer state. |
| PR.IP — Information Protection Processes and Procedures | Bridge operations require disciplined finality, recovery, and change-management procedures. | |
| RC.RP — Recovery Planning | Bridge failures can strand funds or require controlled rollback and restoration. | |
| Recommendation — Use PR.DS to protect transfer integrity and verify message handling across chains. Use PR.IP to define confirmation, failure-handling, and upgrade procedures for the bridge. Use RC.RP to plan and test recovery for bridge outages, reorgs, and failed upgrades. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | A bridge exposed to untrusted inputs can be abused through malformed or malicious messages. |
| T1552 — Unsecured Credentials | Bridge operations often depend on keys or signing material whose theft can enable abuse. | |
| Recommendation — Hunt for malicious bridge inputs and harden the public-facing message path against abuse. Protect bridge signing material and rotate any exposed secrets immediately. | ||
| NIST SP 800-53 Rev 5 | SC-30 — Concealment and Misdirection | Bridges benefit from design patterns that prevent outsiders from manipulating trust assumptions. |
| Recommendation — Apply SC-30-style design discipline to reduce attacker visibility into bridge trust paths. | ||
Practitioner Guidance
What to verify: Treat “bridge correctness” as a proof obligation, not a feature request. Before trusting a design, verify what finality threshold it uses, how it rejects duplicate or reordered messages, and what happens when one chain is temporarily ahead of the other.
What good looks like: The bridge has explicit rules for source-chain confirmation depth, deterministic message state, bounded retries, and rollback-safe upgrade procedures. If the team cannot explain those rules without hand-waving, the bridge is still too fragile to rely on for value transfer.
Practitioner takeaway: The key decision is whether the team is prepared to own cross-chain trust, liveness, and recovery as a product-grade security capability, because without that discipline a custom bridge becomes a liability multiplier rather than an integration shortcut.
Related resources from NHI Mgmt Group
- What breaks when teams build their own AI agent orchestration stack?
- What breaks when teams try to use blockchain for large file storage?
- What breaks when teams try to build distributed orchestration without a controller based control plane?
- What breaks when teams try to move a Swift bridge layer directly into an XCFramework?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
