BGP works by letting autonomous systems exchange routing information and select paths to reachable networks based on advertised prefixes and policy. Because it trusts announcements, attackers can hijack or leak routes if controls are weak. Defenders should validate prefixes, monitor unexpected route changes, and use filtering and route origin protections where available.
How BGP Chooses Paths Between Autonomous Systems
BGP is the inter-domain routing protocol that lets autonomous systems exchange reachability information for IP prefixes. Its job is not to calculate an optimal path in the shortest-path sense, but to learn which networks are reachable, compare available advertisements, and select the best path according to protocol rules and local policy. That policy-driven design is what makes BGP flexible at internet scale.
Each BGP-speaking router advertises the prefixes it can reach, along with path attributes that help neighbours decide whether to accept or prefer a route. The result is a distributed decision process, where different networks can legitimately make different choices for the same destination. That flexibility is useful for traffic engineering, peering, and redundancy, but it also means route selection is shaped by trust in what peers announce.
BGP sessions are established between routers that have an explicit peering relationship, and the protocol then exchanges incremental updates as reachability changes. When a route is learned, the receiving router compares it with existing options and keeps the best one based on the local decision process and policy filters. In practice, this means BGP is as much about routing governance as it is about packet forwarding.
Why Trust and Filtering Matter in BGP
BGP assumes that the announcement a neighbour sends is broadly truthful unless you validate it. That assumption is operationally necessary, but it creates exposure if a peer leaks more-specific prefixes than intended, advertises a prefix it does not control, or accepts a route it should have filtered. Route mistakes can propagate quickly because routers reuse what they learn from other routers.
Prefix validation, route filtering, and origin protections reduce that exposure by constraining which announcements are accepted and propagated. In practical terms, they help answer two questions: is this prefix expected, and is this neighbour authorised to advertise it? Those controls matter because the protocol itself does not provide strong native trust guarantees for every announcement.
Routing policy is therefore a defensive control, not just an engineering preference. A network that accepts every update it hears risks traffic misdirection, traffic blackholing, or unintended transit for prefixes it was never meant to carry. Good BGP hygiene is about shrinking the set of believable routes before they influence forwarding.
How Route Hijacks and Leaks Happen
Route hijacks happen when a network advertises a prefix it should not announce, causing other networks to send traffic toward the wrong place. A leak is different: a valid route is accidentally propagated farther than intended, often because export policy is too broad or a filtering rule is missing. Both problems can disrupt connectivity, expose traffic, or create hard-to-trace routing instability.
The core failure mode is that BGP is built to distribute reachability efficiently, not to independently prove ownership of every prefix. If a forged or accidental announcement looks more attractive than the legitimate one, other networks may install it until the inconsistency is detected and corrected. The larger the propagation, the wider the blast radius.
Where operators need stronger path validation, they can look to source checks, prefix-origin validation, and route filtering technologies that reduce reliance on blind trust. For broader routing-security context, the operational controls described in NIST Cybersecurity Framework 2.0 and NIST Privacy Framework are useful for thinking about governance and validation even when the underlying problem is routing, not privacy.
Risk and Threat Considerations
BGP risk comes from trusting external route advertisements as the basis for traffic delivery. If filtering, validation, or peer configuration is weak, a bad announcement can redirect traffic, create loss of reachability, or expose sensitive flows to an unintended network path.
Failure mechanism: An attacker or misconfigured peer injects, leaks, or prefers an unauthorized prefix advertisement, and downstream routers propagate that decision because BGP treats the update as a normal routing signal.
Impact: Traffic can be diverted, dropped, intercepted, or destabilised across multiple networks before the error is detected and withdrawn.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems inventory | BGP operators need an accurate inventory of routers and peers. |
| PR.DS-01 — Data-at-rest is protected | Route-control data and configuration backups should be protected from tampering. | |
| PR.PS-04 — Configuration management | BGP safety depends on controlled peer, prefix, and export configuration. | |
| Recommendation — Inventory routers and BGP peers so route-policy changes and unexpected adjacencies are detectable. Protect routing configuration data so unauthorized changes do not alter policy. Manage BGP configuration changes through controlled review and approval. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | BGP filtering and route export policy enforce which announcements may flow. |
| AU-6 — Audit Review, Analysis, and Reporting | Unexpected route changes should be logged and reviewed for anomalies. | |
| CM-2 — Baseline Configuration | Known-good BGP policy baselines reduce accidental leaks and hijack exposure. | |
| Recommendation — Enforce route export and import rules to block unauthorized prefix propagation. Review routing logs and alerts for unexpected prefix changes or peer behavior. Baseline BGP peer and filter settings so deviations are obvious and actionable. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | BGP depends on hardened, approved router configurations and filters. |
| CIS-8 — Audit Log Management | Routing anomalies require logging to support detection and response. | |
| Recommendation — Harden router configurations and restrict BGP policy changes to approved baselines. Centralize router logs so route leaks and hijacks can be investigated quickly. | ||
Practitioner Guidance
What to verify: Confirm which prefixes each peer is authorised to advertise, and compare that list with what your routers actually accept and export. If a route appears unexpectedly, treat it as a policy problem first and a packet-forwarding problem second.
Decision rule: If a prefix is critical to business connectivity, require explicit prefix filters and origin validation before accepting it into the routing table. If you cannot validate the origin cleanly, prefer containment over broad acceptance.
What practitioners underestimate: BGP incidents are often caused by ordinary configuration drift, not just malicious action. The practical control objective is to make unexpected announcements fail closed, or at least fail visibly, before they can influence a wider set of neighbours.
Practitioner takeaway: BGP is powerful because it is policy-driven and distributed, but that same design means routing trust must be engineered deliberately, not assumed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org