Join our Newsletter — 33% off our NHI Course

Betweenness Centrality

Betweenness centrality measures how often a node sits on the shortest path between other nodes in a graph. In security analysis, it helps identify techniques or assets that connect multiple attacker stages and are therefore high-value disruption points.

Expanded Definition

Betweenness centrality is a graph metric that highlights nodes acting as bridges between other nodes. In security analysis, it is especially useful for understanding which assets, techniques, accounts, or workflow steps connect otherwise separate parts of an environment. When a node has high betweenness, disruption to that node can interrupt movement, reduce reachability, or expose a chokepoint in an attack path.

Definitions vary slightly depending on whether the graph models infrastructure, identity relationships, or adversary behaviour, but the core idea remains the same: the node is important because many shortest paths pass through it. That makes it more actionable than popularity-style metrics, which only show how many direct links a node has. For governance and risk work, this distinction matters because a highly connected node is not always the most influential, while a bridge node can be critical even with few connections.

In cybersecurity reporting, betweenness centrality is often used alongside graph theory methods in NIST Cybersecurity Framework 2.0 style risk analysis to prioritise choke points, lateral movement paths, or control dependencies. The most common misapplication is treating the metric as a direct measure of risk, which occurs when teams assume a bridge node is dangerous without confirming whether it is actually exploitable or operationally critical.

Examples and Use Cases

Implementing betweenness centrality rigorously often introduces model complexity, requiring organisations to balance analytical precision against the cost of building a graph that accurately reflects real-world dependencies.

  • An identity service account sits between multiple applications and a privileged admin workflow, so its compromise or hardening materially affects several downstream paths.
  • A jump host or remote access gateway bridges user networks and restricted segments, making it a natural candidate for prioritised monitoring and segmentation review.
  • In an attack-path graph, a single technique may connect initial access to credential access, helping analysts spot where a defender can break the sequence.
  • In an NHI inventory, a shared API token or service principal may bridge multiple workloads, making it more operationally sensitive than its direct connection count suggests.
  • A cloud control plane dependency may sit between configuration changes and production resources, revealing a chokepoint that warrants strong logging and change control.

For graph-based defence planning, the value is not the score alone but the context around it. A node with high betweenness may be important because it relays traffic, authorisation, orchestration, or identity assertions, and each of those implications leads to different controls. Security teams often cross-check the graph result against asset criticality, privilege scope, and telemetry coverage before deciding whether the bridge should be segmented, duplicated, or closely watched. Guidance in graph-driven security analysis is still evolving, so the metric should be treated as a prioritisation signal rather than a standalone decision rule.

Why It Matters for Security Teams

Betweenness centrality matters because security teams rarely defend every node equally well. Bridge nodes often become the shortest route for attackers, which makes them attractive for lateral movement, privilege escalation, and operational disruption. If defenders misunderstand the metric, they may overinvest in highly connected assets while missing the quieter dependencies that actually connect sensitive zones.

For identity and NHI governance, the concept is especially useful because service accounts, workload identities, orchestration layers, and secrets distribution paths can function as hidden connectors. That means a graph can reveal where privileged access, token reuse, or shared automation creates concentration risk. In those cases, the right response is not only stronger detection, but also reducing unnecessary bridging, tightening trust boundaries, and re-evaluating whether a single identity or workflow should span multiple domains.

The strongest practical value comes when teams use the metric to inform segmentation, least privilege, and resilience planning under frameworks such as NIST Cybersecurity Framework 2.0. Organisations typically encounter the operational cost of a hidden bridge only after an incident cuts through it, at which point betweenness centrality becomes an unavoidable tool for understanding why the failure propagated.

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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 ID.AM-2 Asset and dependency mapping supports identifying bridge nodes in security graphs.
NIST SP 800-53 Rev 5 AC-4 Boundary and flow controls align to chokepoints revealed by centrality analysis.
NIST SP 800-63 Digital identity assurance is relevant where identities act as graph bridges.
OWASP Non-Human Identity Top 10 NHI-05 NHI guidance highlights overprivileged shared identities that can become bridge nodes.
NIST Zero Trust (SP 800-207) SC-7 Zero Trust segmentation aligns with limiting high-centrality pathways between trust zones.

Map critical dependencies so bridge nodes can be prioritised for protection and monitoring.