Policy-based routing

Policy-based routing is the practice of sending traffic along a chosen path based on application identity, performance, or business rules rather than fixed static routes. In SD-WAN, it is the mechanism that turns routing into a governed decision rather than a purely network-layer default.

Expanded Definition

Policy-based routing is a governed forwarding decision: traffic is steered by application identity, user or service context, performance thresholds, or business intent instead of a single destination-only route table. In NHI security, that matters because the decision point can determine whether a request is allowed to traverse a trusted segment, a brokered inspection path, or a restricted control plane. The concept overlaps with SD-WAN, segmentation, and Zero Trust, but no single standard governs this yet, and usage in the industry is still evolving. For that reason, teams should anchor the term to operational policy logic, not to a specific vendor feature set. NIST’s NIST Cybersecurity Framework 2.0 provides a useful governance lens for defining, monitoring, and reviewing such routing decisions.

The most common misapplication is treating policy-based routing as a performance shortcut, which occurs when teams use it to bypass governance controls without documenting the identity or risk conditions behind the path selection.

Examples and Use Cases

Implementing policy-based routing rigorously often introduces operational complexity, requiring organisations to weigh lower latency and tighter segmentation against policy maintenance, troubleshooting effort, and rule drift.

• Routing service-to-service traffic through an inspection zone when the calling workload has access to secrets that require tighter monitoring, as discussed in Top 10 NHI Issues.
• Sending API calls from an agentic workflow over a private path only when the workload identity is verified and the destination is a regulated system, aligning with NIST Cybersecurity Framework 2.0.
• Directing backups or replication traffic to a lower-cost link during business hours while preserving a higher-assurance path for administrative NHI traffic.
• Forcing high-risk requests to a quarantine segment when the source service account is new, unrotated, or associated with excessive privilege, a pattern covered in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

In practice, the value comes from making route choice auditable: who or what initiated the flow, which policy decided the path, and which controls were in force at that moment.

Why It Matters in NHI Security

Policy-based routing becomes security-relevant because the route itself can become part of the trust boundary. If routing rules are overly broad, an attacker who compromises an NHI can move laterally through paths that were intended for business exceptions only. If the rules are too rigid, teams bypass them during incident response and create shadow paths that are harder to monitor. NHIMG data shows that 97% of NHIs carry excessive privileges, which means path selection often interacts with privilege exposure rather than operating independently. The routing policy should therefore be reviewed alongside entitlement scope, secret placement, and inspection requirements, not as a pure networking concern. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is especially relevant when auditors need evidence that traffic paths were chosen for documented security reasons rather than convenience.

Organisations typically encounter the consequence of policy-based routing only after a breach investigation or service outage, at which point the routing policy becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does policy-based access control reduce risk for NHI environments?
• What is the difference between policy compliance and evidence-based compliance for AI systems?
• When does policy-based access control fail for workloads and agents?
• What is the difference between CSPM and policy-based access control?