Quantifying the Blast Radius: Centrality-Based Criticality Modeling for Infrastructure Risk
A Structural Risk Case Study — NexaCore Financial Technologies
Author
Patrick Lefler
Published
July 2, 2026
Abstract
Centrality scores are easy to compute and easy to misread. A node with high betweenness centrality is mathematically a chokepoint, but without a topology specific enough to make that chokepoint legible, the finding remains abstract. This project builds a 90-node synthetic infrastructure topology for a fintech estate and applies three independent centrality measures – betweenness, eigenvector, and PageRank – to identify structurally critical nodes, then validates each candidate through direct node-removal simulation rather than relying on the centrality score alone. The three metrics are deliberately compared rather than averaged: where they agree, the finding is robust; where they diverge, the divergence itself indicates that a node is critical for different structural reasons. A business impact layer maps each node to estimated revenue exposure and customer-facing consequence, converting a graph-theoretic ranking into a board-legible prioritization. The analysis surfaces an authentication gateway with no redundant path serving as a structural single point of failure for the majority of revenue-generating traffic – a finding invisible to conventional infrastructure inventories but immediate once the dependency graph is traversed.
Introduction
Infrastructure risk assessments typically produce a list: servers, services, databases ranked by tier, by criticality label, by compliance classification. What they rarely produce is an answer to the question that matters most in an incident — if this one thing fails, how much of the business breaks with it? The list format cannot answer that question. Dependencies are transitive. A database that two services read directly is depended on by every service that depends on those two services. A shared authentication gateway that appears in no formal risk register may sit on every path between a customer and their account.
Graph theory is the right framework for this class of problem. When infrastructure is modeled as a directed dependency graph, the question “what breaks if X fails” becomes a graph computation: remove node X and measure how many previously reachable node pairs are now disconnected. The answer is precise, reproducible, and independent of whatever labels were applied to X in the last risk register update.
This case study applies that framework to NexaCore Financial Technologies’ infrastructure estate. The topology is synthetic but designed to reflect the structural patterns of a real fintech operation: a few highly-connected data stores, a small number of cross-cutting services that every authenticated transaction passes through, a set of external dependencies with no fallback path, and a long tail of single-purpose nodes that exist in the graph but carry limited systemic weight. Three centrality metrics – betweenness, eigenvector, and PageRank – are computed independently and compared rather than averaged. Where they agree, the finding is structurally robust. Where they diverge, the divergence is itself informative: a node can be critical for different structural reasons, and those reasons drive different remediation responses.
The analysis is paired with direct blast radius simulation. Centrality metrics are computed from graph topology alone; they do not account for the business weight of what a node enables. Blast radius simulation fills that gap. One node in this topology – a third-party KYC/AML vendor – ranks 74th by composite centrality and 52nd by blast radius. Its removal breaks nine reachable pairs in the full graph. Three of those pairs involve the client onboarding workflow, the compliance reporting engine, and real-time fraud screening. Centrality would deprioritize it. Operational context cannot.
Centrality as a Risk Metric
Infrastructure risk practitioners have long used ad-hoc notions of criticality – “this is a Tier 1 system” – without a systematic method for deriving those tiers from structure rather than assertion. Graph centrality provides that method. Three measures are relevant here, each answering a different structural question.
Betweenness centrality counts how often a node appears on the shortest path between every other pair of nodes in the graph. A node with high betweenness is a chokepoint: traffic, data, and control flow converge through it. In an infrastructure dependency graph, high betweenness indicates that many workflows pass through this node rather than terminating at it. The authentication gateway is a canonical example – it stores nothing, but every authenticated request to every downstream service is routed through it.
Eigenvector centrality measures influence by the quality of a node’s connections, not just their quantity. A node connected to many high-centrality nodes scores highly even if its raw degree is modest. In a dependency graph, high eigenvector centrality indicates that a node sits in the structural center of the most well-connected part of the estate – surrounded by other high-value nodes that themselves have many dependents. Core data stores tend to dominate this metric, because the services that read them are themselves highly connected.
PageRank follows the same intuition as eigenvector centrality but uses a random-walk formulation that handles directed graphs more cleanly. In the directed dependency graph used here, edges point from dependents to dependencies (A depends on B means A -> B). PageRank accumulates at nodes with many incoming edges from high-PageRank sources – nodes that are depended upon by other well-depended-upon nodes. The Secrets Vault is a characteristic example: every service depends on it for database credentials, and those services are themselves critical.
Using three metrics rather than one is not hedging – it is the analysis. A node that ranks in the top tier on all three measures is unambiguously critical regardless of framing. A node that ranks highly on betweenness alone but not on PageRank or eigenvector is a pass-through chokepoint rather than a foundational data dependency, which points to a different remediation (add redundant routing versus add read replicas). A node that scores low on all three but produces high blast radius in simulation is the most operationally dangerous type: invisible to centrality analysis, material in practice.
The Infrastructure Topology
NexaCore’s synthetic estate spans 90 nodes across seven tiers, connected by 155 directed dependency edges. The topology was designed from structural principles rather than node count: fan-out ratios, redundancy patterns, and the placement of six deliberate structural risks were specified before any node was added.
nodes |>count(tier) |>mutate(tier =fct_reorder(tier, n)) |>ggplot(aes(x = n, y = tier, fill = tier)) +geom_col(width =0.65, show.legend =FALSE) +geom_text(aes(label = n), hjust =-0.3, size =3.5, color = brand_text) +scale_fill_manual(values = tier_colors) +scale_x_continuous(expand =expansion(mult =c(0, 0.12))) +labs(title ="Node Count by Tier",x ="Number of nodes",y =NULL,caption ="90 nodes total across 7 tiers." )
Figure 1: Node distribution across tiers. Application / Service and Data tiers account for the majority of the topology; the long tail of lower-degree nodes in those tiers creates the sparsity that makes high-centrality nodes stand out.
Display code
in_deg <- edges |>count(to, name ="in_degree") |>right_join(nodes |>select(id, tier), by =c("to"="id")) |>mutate(in_degree =replace_na(in_degree, 0L))in_deg |>ggplot(aes(x = in_degree, fill = tier)) +geom_histogram(binwidth =1, color ="white", linewidth =0.3) +scale_fill_manual(values = tier_colors, name ="Tier") +scale_x_continuous(breaks =seq(0, 20, 2)) +scale_y_continuous(expand =expansion(mult =c(0, 0.05))) +labs(title ="In-Degree Distribution",x ="Number of nodes that depend on this node (in-degree)",y ="Count",caption ="In-degree = number of direct upstream dependents. Computed from edges.csv." )
Figure 2: In-degree distribution (number of nodes that depend on each node). The long tail of low-degree nodes and the small number of high-degree hubs are the structural signature that makes centrality analysis meaningful. Most nodes have 0–2 dependents; a handful have 10 or more.
The degree distribution confirms the design intent: roughly 60% of nodes have in-degree of zero or one (they depend on others but few depend on them). The nodes with in-degree of 10 or higher – the right tail of Figure 2 – are the candidates the centrality analysis will examine in detail.
The graph density of 0.0194 confirms the intended sparsity: fewer than 2% of all possible directed edges exist. This is consistent with real enterprise topologies where each service depends on a small number of immediate dependencies rather than being globally connected. The sparsity is what makes high-centrality nodes analytically significant – they stand out against a background of low-connectivity nodes.
Figure 3: Full dependency graph, nodes sized by composite centrality score. The Authentication Gateway, Secrets Vault, and Shared Message Queue are visually dominant. Risk nodes are outlined in red. The majority of nodes cluster at small sizes, confirming the long-tail degree distribution.
Centrality Analysis
All three centrality metrics were pre-computed on the full dependency graph and are read directly from data/centrality_scores.csv. The interactive table below allows sorting by any individual metric; the analysis that follows focuses on where the rankings agree and where they diverge.
top15 <- centrality |>slice_head(n =15) |>select(name, betweenness_norm, pagerank_norm, eigenvector_norm) |>pivot_longer(cols =c(betweenness_norm, pagerank_norm, eigenvector_norm),names_to ="metric",values_to ="score" ) |>mutate(metric =recode(metric,betweenness_norm ="Betweenness",pagerank_norm ="PageRank",eigenvector_norm ="Eigenvector" ),name =fct_reorder(name, score, .fun = sum) )ggplot(top15, aes(x = score, y = name, fill = metric)) +geom_col(position ="dodge", width =0.7) +scale_fill_manual(values = metric_colors, name ="Metric") +scale_x_continuous(expand =expansion(mult =c(0, 0.05)),labels = scales::number_format(accuracy =0.01)) +labs(title ="Top 15 Nodes: Centrality Score by Metric",subtitle ="Divergence between metrics indicates different structural risk profiles",x ="Normalized score [0, 1]",y =NULL,caption ="Scores normalized independently per metric. Composite = mean of three." )
Figure 4: Top 15 nodes by composite centrality score, broken out by individual metric. Nodes where all three bars are tall are structurally critical by every measure. Nodes with one dominant bar are critical for a specific structural reason – which drives the remediation approach.
The divergence pattern in Figure 4 is the analysis’s primary finding. secrets-vault leads on both PageRank and eigenvector but has near-zero betweenness – it is a deep dependency that everything ultimately relies on, but it is not a pass-through node on any workflow’s critical path. auth-gateway shows the opposite pattern: near-perfect betweenness with modest PageRank and eigenvector – it is the routing chokepoint for authenticated traffic, but it stores nothing that other nodes depend on for data. message-queue scores highly on all three, making it the topology’s most consistently critical node by graph structure alone.
The divergence between secrets-vault and auth-gateway is not an analytical ambiguity – it is a finding. Remediating auth-gateway means adding a redundant routing path so that authentication is no longer a single-lane bottleneck. Remediating secrets-vault means introducing a secondary vault instance or a local credential cache so that vault unavailability does not simultaneously revoke every service’s database access. The metrics agree that both are critical; they disagree in exactly the way that forces the right remediation conversation.
Display code
centrality |>mutate(risk_label =if_else(risk_node =="True", name, ""),point_size =2+ eigenvector_norm *8,# log1p transformation spreads the origin cluster while preserving zerospr_log =log1p(pagerank_norm *100),bw_log =log1p(betweenness_norm *100) ) |>ggplot(aes(x = pr_log, y = bw_log, size = point_size, fill = tier)) +geom_point(shape =21, color ="white", stroke =0.4, alpha =0.85) + ggrepel::geom_text_repel(aes(label = risk_label),size =2.8, color = brand_text, max.overlaps =20,box.padding =0.5, min.segment.length =0.2 ) +scale_fill_manual(values = tier_colors, name ="Tier") +scale_size_identity() +annotate("text", x =4.4, y =0.4,label ="High PageRank\nLow betweenness\n(foundational dependency)",size =2.8, color ="#888888", hjust =0.5) +annotate("text", x =0.4, y =4.4,label ="High betweenness\nLow PageRank\n(routing chokepoint)",size =2.8, color ="#888888", hjust =0.5) +labs(title ="Betweenness vs. PageRank",subtitle ="Point size proportional to eigenvector centrality. Risk nodes labelled.",x ="PageRank -- log1p(score x 100)",y ="Betweenness -- log1p(score x 100)",caption ="Log1p transformation applied to spread origin cluster. Both axes: log1p(normalized score x 100)." )
Figure 5: Betweenness vs. PageRank for all 90 nodes on log1p-transformed axes, sized by eigenvector centrality. Log transformation separates the dense cluster near the origin without excluding zero values. Nodes on the horizontal axis (high PageRank, low betweenness) are foundational data dependencies; nodes on the vertical axis are routing chokepoints.
Blast Radius Validation
Centrality metrics are structural properties of the graph. They say nothing directly about the business consequence of a node’s failure. Blast radius simulation fills that gap: for each node, remove it from the graph and count how many previously reachable node pairs are now disconnected. The result is a direct, simulation-derived measure of structural impact that does not depend on any assumptions about business weight.
Table 4: Top 20 Nodes by Blast Radius (broken reachable pairs on node removal)
Node
Tier
Blast Radius
Betweenness
PageRank
Eigenvector
Composite
Authentication Gateway
Edge / Perimeter
285
1.000
0.151
0.024
0.392
Web Application Firewall
Edge / Perimeter
100
0.210
0.017
0.000
0.076
Customer Portal
Core Business Systems
61
0.129
0.010
0.040
0.060
CDN / Edge Cache
Edge / Perimeter
58
0.000
0.000
0.000
0.000
Secrets Vault
Data
55
0.000
1.000
1.000
0.667
Cloud IAM Provider
External Dependency
52
0.000
0.010
0.040
0.017
Shared Message Queue
Data
51
0.107
0.253
0.492
0.284
Primary Load Balancer
Edge / Perimeter
50
0.204
0.024
0.000
0.076
Secondary Load Balancer
Edge / Perimeter
50
0.204
0.024
0.000
0.076
Core Financial Ledger
Core Business Systems
46
0.109
0.222
0.177
0.170
Payment Processing Service
Application / Service
46
0.180
0.010
0.040
0.077
Production K8s Cluster
Infrastructure
45
0.146
0.138
0.000
0.095
Real-Time Risk Engine
Core Business Systems
29
0.064
0.030
0.048
0.048
Core Ledger Database
Data
28
0.032
0.223
0.210
0.155
Primary Cache Cluster
Data
28
0.093
0.103
0.169
0.122
Client Onboarding Service
Core Business Systems
26
0.073
0.010
0.040
0.041
Dead Letter Queue
Data
26
0.000
0.249
0.476
0.242
Audit Trail Service
Core Business Systems
25
0.049
0.032
0.048
0.043
Notification Service
Application / Service
25
0.064
0.005
0.024
0.031
Workflow Orchestration Svc
Application / Service
20
0.030
0.057
0.089
0.059
Display code
blast_results |>arrange(desc(blast_radius)) |>slice_head(n =20) |>mutate(node_label =fct_reorder(name, blast_radius),is_risk = risk_node =="True" ) |>ggplot(aes(x = blast_radius, y = node_label, fill = tier)) +geom_col(width =0.7) +geom_text(aes(label = blast_radius), hjust =-0.3,size =3.2, color = brand_text) +scale_fill_manual(values = tier_colors, name ="Tier") +scale_x_continuous(expand =expansion(mult =c(0, 0.12))) +labs(title ="Blast Radius: Top 20 Nodes",subtitle ="Broken reachable node pairs on node removal from the dependency graph",x ="Broken reachable pairs",y =NULL,caption ="Baseline: 566 reachable pairs across the 90-node topology." )
Figure 6: Blast radius for the top 20 nodes by broken reachable pairs. The Authentication Gateway’s dominance (285 pairs) reflects its position as the sole authenticated-traffic routing point. The gap between auth-gateway and the second-ranked node (waf at 100) is itself a risk signal – this is not a smooth distribution.
Display code
centrality |>mutate(blast_log =log1p(blast_radius),kyc_label =if_else(node_id =="kyc-vendor", "KYC / AML Vendor\n(centrality rank 74, blast = 9)", ""),high_label =if_else(composite_score >0.25& blast_radius >40, name, ""),label =if_else(kyc_label !="", kyc_label, high_label) ) |>ggplot(aes(x = composite_score, y = blast_log, fill = tier)) +geom_point(shape =21, color ="white", stroke =0.4, size =3.5, alpha =0.85) + ggrepel::geom_text_repel(aes(label = label),size =2.8, color = brand_text, max.overlaps =15,box.padding =0.5, min.segment.length =0.2 ) +scale_fill_manual(values = tier_colors, name ="Tier") +# Annotate the KYC counterexample zone (log1p(5)=1.79, log1p(15)=2.77)annotate("rect", xmin =0, xmax =0.06, ymin =log1p(4), ymax =log1p(20),fill = brand_highlight, alpha =0.07) +annotate("text", x =0.03, y =log1p(25),label ="Low centrality\nnon-trivial blast\n(centrality misses these)",size =2.6, color = brand_highlight, hjust =0.5) +scale_y_continuous(breaks =log1p(c(0, 5, 10, 25, 50, 100, 200, 285)),labels =c("0","5","10","25","50","100","200","285") ) +labs(title ="Composite Centrality vs. Blast Radius",subtitle ="Nodes in the highlighted zone would be deprioritized by centrality alone",x ="Composite centrality score",y ="Blast radius (broken reachable pairs, log scale)",caption ="Y-axis: log1p transformation. Composite score = mean of normalized betweenness, PageRank, and eigenvector." )
Figure 7: Composite centrality score vs. blast radius (log1p scale) for all 90 nodes. Log transformation separates the dense lower cluster without excluding low-blast nodes. The KYC/AML Vendor sits in the highlighted zone – low composite centrality, non-trivial blast radius – and would be deprioritized by a centrality-only framework.
The KYC/AML Vendor sits in the annotated zone in Figure 7: composite centrality of 0.017 (74th of 90), blast radius of 9. On a linear scale that figure would have been buried in the origin cluster, invisible. The log transformation makes it readable – and the position is the point. The pairs it breaks are specific: all paths from the client onboarding service, the compliance reporting engine, and the real-time fraud screening service to their downstream dependencies disappear when the vendor is removed. There is no fallback path. Onboarding stops. Compliance submissions fail. Fraud signals go dark. A centrality-only prioritization framework would not flag this node for remediation at all.
Business Impact Translation
Structural blast radius measures connectivity loss. Business impact translates that into revenue and customer-facing consequence. Each node in the topology carries a revenue_weight attribute on a 1–5 scale reflecting its proximity to revenue-generating workflows. The composite criticality score used for remediation prioritization combines structural blast radius with this business weight.
Table 5: Top 20 Nodes by Composite Criticality Score (blast radius 60% + revenue weight 40%)
Node
Tier
Blast Radius
Revenue Weight
Criticality Score
SPOF
Authentication Gateway
Edge / Perimeter
285
5
1.000
FALSE
Customer Portal
Core Business Systems
61
5
0.527
FALSE
Secrets Vault
Data
55
5
0.514
FALSE
Shared Message Queue
Data
51
5
0.506
FALSE
Core Financial Ledger
Core Business Systems
46
5
0.495
FALSE
Payment Processing Service
Application / Service
46
5
0.495
FALSE
Production K8s Cluster
Infrastructure
45
5
0.493
FALSE
Core Ledger Database
Data
28
5
0.457
FALSE
Web Application Firewall
Edge / Perimeter
100
3
0.449
FALSE
Legacy Billing Service
Core Business Systems
18
5
0.436
FALSE
Customer Identity Database
Data
13
5
0.425
FALSE
Payment Network (SEPA/SWIFT)
External Dependency
8
5
0.415
FALSE
Real-Time Risk Engine
Core Business Systems
29
4
0.379
FALSE
Service Mesh Control Plane
Infrastructure
20
4
0.360
FALSE
Account Management Service
Application / Service
19
4
0.358
FALSE
Production Network Segment
Infrastructure
17
4
0.354
FALSE
Fraud Detection Service
Application / Service
16
4
0.352
FALSE
Order Management Service
Application / Service
15
4
0.350
FALSE
Transaction History Database
Data
15
4
0.350
FALSE
Limits & Controls Service
Application / Service
13
4
0.345
FALSE
Display code
set.seed(42)impact_full <- blast_results |>filter(blast_radius >0) |>mutate(rev_norm = revenue_weight /max(revenue_weight),criticality_score = blast_norm *0.6+ rev_norm *0.4,blast_log =log1p(blast_radius),high_label =if_else(criticality_score >0.45, name, "") )ggplot(impact_full,aes(x = revenue_weight, y = blast_log,size = criticality_score, fill = tier)) +geom_point(shape =21, color ="white", stroke =0.4, alpha =0.85,position =position_jitter(width =0.18, height =0, seed =42) ) + ggrepel::geom_text_repel(aes(label = high_label, y = blast_log),size =2.8, color = brand_text, max.overlaps =15,box.padding =0.5, min.segment.length =0.2 ) +scale_fill_manual(values = tier_colors, name ="Tier") +scale_size_continuous(range =c(2, 10), name ="Criticality score") +scale_x_continuous(breaks =1:5,labels =c("1\n(low)","2","3","4","5\n(high)")) +scale_y_continuous(breaks =log1p(c(0, 5, 10, 25, 50, 100, 200, 285)),labels =c("0","5","10","25","50","100","200","285") ) +labs(title ="Blast Radius vs. Revenue Weight",subtitle ="Composite criticality combines structural exposure with business consequence",x ="Revenue weight (1 = low, 5 = high)",y ="Blast radius (broken reachable pairs, log scale)",caption ="Y-axis: log1p transformation. Horizontal jitter applied within each revenue weight band. Only nodes with blast radius > 0 shown." )
Figure 8: Blast radius (log scale) vs. revenue weight for nodes with blast radius > 0. Horizontal jitter separates nodes sharing the same integer revenue weight. Point size reflects composite criticality score. The Authentication Gateway occupies the top-right corner alone – maximum blast radius, maximum revenue weight.
Remediation Prioritization
The remediation backlog below is derived directly from the composite criticality ranking. Each entry includes the structural finding, the remediation type, and an effort classification. Remediation types are categorized as: Add redundancy (introduce a secondary path or failover), Scope reduction (reduce the blast radius by decoupling non-essential dependencies), or External governance (contractual and architectural controls for third-party nodes).
Display code
remediation <-tribble(~priority, ~node, ~finding,~remediation_type, ~effort,1L, "Authentication Gateway","Sole authenticated-traffic path; removal breaks 285 pairs. No secondary route exists.","Add redundancy", "High",2L, "Web Application Firewall","All inbound traffic routes through a single WAF instance; 100 broken pairs on removal.","Add redundancy", "Medium",3L, "Secrets Vault","Every service-to-database credential passes through one vault; 55 broken pairs. Top PageRank and eigenvector.","Add redundancy", "Medium",4L, "Shared Message Queue","14 services publish/subscribe through one unpartitioned cluster; 51 broken pairs.","Scope reduction", "High",5L, "Core Financial Ledger","Single ledger service; 46 broken pairs. No read replica or secondary write path.","Add redundancy", "High",6L, "KYC / AML Vendor API","Low centrality (rank 74) but onboarding, compliance, and fraud all block on it with no fallback.","External governance", "Medium",7L, "Core Ledger Database","Single primary Postgres; 28 broken pairs. Relied on by ledger service and downstream consumers.","Add redundancy", "High",8L, "Legacy Billing Service","All payment reconciliation paths route through a pre-migration system; 18 broken pairs.","Scope reduction", "High",9L, "Primary Cache Cluster","Session state and rate-limit counters share one Redis cluster; 28 broken pairs.","Add redundancy", "Low",10L, "Production K8s Cluster","Primary container orchestration for all workloads; 45 broken pairs on removal.","Add redundancy", "High")kable( remediation,format ="html",caption ="Table 6: Prioritized Remediation Backlog",col.names =c("Priority", "Node", "Finding", "Remediation Type", "Effort")) |>kable_styling(bootstrap_options =c("striped", "hover", "condensed"),full_width =TRUE,position ="left",font_size =13 )
Table 6: Prioritized Remediation Backlog
Priority
Node
Finding
Remediation Type
Effort
1
Authentication Gateway
Sole authenticated-traffic path; removal breaks 285 pairs. No secondary route exists.
Add redundancy
High
2
Web Application Firewall
All inbound traffic routes through a single WAF instance; 100 broken pairs on removal.
Add redundancy
Medium
3
Secrets Vault
Every service-to-database credential passes through one vault; 55 broken pairs. Top PageRank and eigenvector.
Add redundancy
Medium
4
Shared Message Queue
14 services publish/subscribe through one unpartitioned cluster; 51 broken pairs.
Scope reduction
High
5
Core Financial Ledger
Single ledger service; 46 broken pairs. No read replica or secondary write path.
Add redundancy
High
6
KYC / AML Vendor API
Low centrality (rank 74) but onboarding, compliance, and fraud all block on it with no fallback.
External governance
Medium
7
Core Ledger Database
Single primary Postgres; 28 broken pairs. Relied on by ledger service and downstream consumers.
Add redundancy
High
8
Legacy Billing Service
All payment reconciliation paths route through a pre-migration system; 18 broken pairs.
Scope reduction
High
9
Primary Cache Cluster
Session state and rate-limit counters share one Redis cluster; 28 broken pairs.
Add redundancy
Low
10
Production K8s Cluster
Primary container orchestration for all workloads; 45 broken pairs on removal.
Add redundancy
High
Four of the ten items require high effort – they are architectural changes (redundant auth routing, message queue partitioning, ledger service replication, legacy billing decoupling) rather than configuration changes. The remaining six are medium or low effort. The KYC/AML Vendor entry (rank 6) is the only item driven by blast radius simulation rather than centrality; without the simulation step, it would not appear in this list at all.
Key Insights & Conclusion
The topology’s most consequential structural risk is not its most prominent one. The Authentication Gateway produces the highest blast radius in the graph – 285 broken reachable pairs, against a baseline of 566 – which means a single-node failure would sever roughly half of all reachable paths in the estate. It also has the highest betweenness centrality by a wide margin. Neither of these facts appears in NexaCore’s infrastructure inventory, because the inventory records what a system does, not where it sits in the dependency structure.
The divergence between secrets-vault and auth-gateway illustrates why three metrics are more informative than one. Both nodes are unambiguously critical. They are critical in different ways: auth-gateway is a routing chokepoint that sits on every authenticated workflow’s shortest path, while secrets-vault is a foundational dependency that every data-accessing service relies on transitively. Remediating auth-gateway requires a redundant authentication routing layer – an active-active deployment behind the load balancers. Remediating secrets-vault requires a secondary vault instance with automatic unsealing, plus a local credential cache so that a brief vault outage does not simultaneously revoke every service’s database access. These are different architectural decisions. A framework that averaged the three centrality scores into a single ranking and recommended “address the top N nodes” would obscure the distinction.
The KYC/AML Vendor is the analysis’s sharpest finding for a risk audience. It ranks 74th by composite centrality – not because it is unimportant, but because it has few direct dependents and stores no data that others read. It is a leaf node in the graph. What centrality cannot see is that the three services depending on it – onboarding, compliance reporting, and fraud screening – each block synchronously on its availability, and none has a circuit breaker or cached fallback. The node-removal simulation surfaces what structural centrality cannot: a commercially and operationally significant failure mode that a centrality-only framework would route straight to the bottom of the remediation backlog.
The broader principle is straightforward. Centrality metrics are necessary but not sufficient for infrastructure risk prioritization. They identify structural importance from graph topology alone, which makes them fast, systematic, and independent of assertion. What they cannot capture is the difference between a node that is structurally peripheral but operationally blocking and a node that is structurally central but has robust redundant paths. Blast radius simulation bridges that gap. Used together, the two approaches produce a remediation backlog that is both graph-theoretically defensible and operationally grounded – which is the combination a CISO actually needs to take findings to a board.
Rendered with Quarto. Analysis performed in R using igraph, tidygraph, ggraph, tidyverse, and kableExtra. Centrality and blast radius pre-computed in Python (compute_centrality.py). Synthetic infrastructure topology generated via generate_infra_data.py. All nodes, services, and topologies are fictitious.
