Teams should evaluate whether the network can sustain real-world transaction volumes without introducing bottlenecks, higher fees, or unacceptable confirmation delays. The core question is not just peak throughput, but whether the architecture can scale while preserving security, decentralisation, and operational usability. If performance improvements require heavier infrastructure, centralisation risk often rises with them.
Why This Matters for Security Teams
Throughput is not just a product metric. For security and platform teams, it determines whether a distributed ledger can process enough legitimate activity to be useful without pushing users into delays, retry storms, or expensive workarounds. If a network scales by concentrating validation, storage, or block production into fewer hands, it may improve speed while weakening the trust model that made the ledger attractive in the first place. That tradeoff is especially visible when adoption moves from pilot traffic to business-critical volume.
The practical issue is that mainstream adoption changes the adversary model. Higher load can expose queueing bottlenecks, mempool contention, governance delays, and fee volatility, all of which create pressure to simplify architecture or delegate trust. Security teams should treat that as a resilience question as much as a performance question, consistent with the risk-and-governance emphasis in the NIST Cybersecurity Framework 2.0. NHIMG’s analysis of adoption and visibility gaps in The State of Non-Human Identity Security shows how quickly confidence erodes when systems become harder to observe and control at scale. In practice, many teams discover throughput limits only after transaction growth has already made redesign expensive.
How It Works in Practice
Security teams should evaluate throughput in three layers: transaction execution, consensus, and operational overhead. A ledger can look fast in lab conditions yet fail under realistic usage because latency rises as nodes sync, signatures accumulate, and finality rules become stricter. The right question is not “how many transactions per second at peak?” but “what sustained rate can the network hold under normal failure conditions without weakening decentralisation or increasing operator trust?”
That means testing not only raw capacity but also how the system behaves when fees rise, nodes fall behind, or consensus participants are geographically distributed. If users or applications must batch transactions, rely on layer-2 systems, or wait through longer confirmation windows, security teams should assess whether those compensating mechanisms introduce new trust assumptions. The operational pattern is similar to what NHIMG highlights in The State of Non-Human Identity Security: loss of visibility and control tends to become a governance problem as soon as scale increases.
- Measure sustained throughput, not short bursts, and test against realistic confirmation targets.
- Model the cost of scaling nodes, storage, and bandwidth before assuming linear growth.
- Check whether higher performance depends on a smaller validator set, privileged operators, or off-chain trust.
- Validate how the network behaves during congestion, reorgs, or partial outages.
For policy and control mapping, the NIST Cybersecurity Framework 2.0 is useful for framing availability, resilience, and recovery expectations alongside confidentiality and integrity. These controls tend to break down when transaction volume spikes faster than node synchronization, because backlogs then force either longer confirmation times or more centralised infrastructure.
Common Variations and Edge Cases
Tighter throughput targets often increase operational cost, requiring organisations to balance user experience against decentralisation and auditability. That tradeoff is not always a failure. In some permissioned or consortium settings, a smaller validator set may be acceptable if governance is explicit and participants are known. In open networks, the same shortcut can undermine the security model because the system starts relying on fewer actors to keep processing reliable.
Best practice is evolving around whether to use base-layer settlement for high-value assurance and off-chain mechanisms for volume. There is no universal standard for this yet, so teams should be clear about what is being optimised: payment latency, settlement finality, or public verifiability. A network may be technically secure while still unsuitable for mainstream adoption if fees are unpredictable or confirmation time is too variable for consumer or enterprise workflows. Teams should also watch for centralisation drift in validator hosting, RPC access, and sequencer operations, because those layers can become the real bottleneck even when headline TPS looks strong. For a governance lens on how scale changes visibility and control, NHIMG’s research on NHI security confidence is a useful reminder that operational complexity often appears before formal risk registers catch up.
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 Zero Trust (SP 800-207) and NIST AI RMF set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.SC-5 | Throughput tradeoffs affect supplier and infrastructure resilience. |
| NIST Zero Trust (SP 800-207) | Scaling often shifts trust to more infrastructure layers. | |
| NIST AI RMF | AI RMF helps frame availability and governance risks from scale. | |
| DORA | Art. 9 | Operational resilience matters when adoption drives congestion. |
Assess ledger scaling dependencies and verify the network still meets availability targets under peak and failure conditions.
Related resources from NHI Mgmt Group
- How should teams think about ServiceNow in an NHI programme?
- What do security teams get wrong about trust in mainstream crypto adoption?
- How should security teams implement cloud authentication in distributed environments without creating new access sprawl?
- What do security teams get wrong about using blockchain for identity data protection?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
