Category: Cyber Resilience

Sovereign Cryptography and the Strategic Evolution of the Guomi Suite: A Technical Analysis of SM3 and SM4

Sovereign Cryptography and the Strategic Evolution of the Guomi Suite: A Technical Analysis of SM3 and SM4

The global transition toward decentralised and sovereign cryptographic standards represents one of the most significant shifts in the history of information security. For decades, the international community relied almost exclusively on a handful of standards, primarily those vetted by the National Institute of Standards and Technology (NIST) in the United States. However, the emergence of the ShāngMì (SM) series, collectively known as the Guomi suite, has fundamentally altered this landscape.1 These Chinese national standards, including the SM2 public-key algorithm, the SM3 hash function, and the SM4 block cypher, were initially developed to secure domestic critical infrastructure but have since achieved international recognition through ISO/IEC standardisation and integration into global protocols like TLS 1.3.2

Following my 2023 article on SM2 Public Key Encryption, this follow-on provides a technical evaluation of the Guomi suite, focusing on the architectural nuances of SM3 and SM4. And considering I have spent the last 24 months under the tutelage of some of the finest Cryptographers and Infosec Practioners in the world at the ISG, Royal Holloway, University of London, this one should be more grounded and informative.

I have tried to analyse the computational efficiency, keyspace resilience, and the strategic importance of “cover-time.” This report examines why these algorithms are increasingly viewed as viable, and in some contexts superior, alternatives to Western counterparts like SHA-256 and AES. Furthermore, it situates these technical developments within the broader geopolitical context of cryptographic sovereignty, exploring the drive for independent verification without ideological bias.

Technical Architecture of the SM3 Hashing Algorithm

The SM3 cryptographic hash algorithm, standardised as ISO/IEC 10118-3:2018, is a robust 256-bit hash function designed for high-security commercial applications.3 Built upon the classic Merkle-Damgård construction, it shares structural similarities with the SHA-2 family but introduces specific innovations in its compression function and message expansion logic that significantly improve its resistance to collision and preimage attacks.6

Iteration Compression and Message Expansion

SM3 processes input messages of length bits through an iterative compression process. The message is first padded to a length that is a multiple of 512 bits. Specifically, the padding involves appending a “1” bit, followed by zero bits, where is the smallest non-negative integer satisfying .6 Finally, a 64-bit representation of the original message length is appended.6

The padded message is divided into 512-bit blocks . For each block, a message expansion process generates 132 words ( and ).3 This expansion is more complex than that of SHA-256, utilizing a permutation function to enhance nonlinearity and bit-diffusion.6

The expansion logic for a message block is defined as follows:

  1. Divide into 16 words .
  2. For to :
  3. For to :

    3

This expanded word set is then processed through a 64-round compression function utilising eight 32-bit registers ( through ). The compression function employs two sets of Boolean functions, and , which vary depending on the round number.3

Round Range (j)FFj​(X,Y,Z)GGj​(X,Y,Z)Constant Tj​
0x79cc4519
0x7a879d8a

The split in logic between the first 16 rounds and the subsequent 48 rounds is a strategic defence against bit-tracing. The initial rounds rely on pure XOR operations to prevent linear attacks, while the later rounds introduce nonlinear operations to ensure high diffusion and resistance to differential cryptanalysis.6

Performance and Computational Efficiency

While SM3 is structurally similar to SHA-256, its “Davies-Meyer” construction utilises XOR for chaining values, whereas SHA-256 uses modular addition.8 This architectural choice, combined with the more complex message expansion, historically led to the perception that SM3 is slower in software.8 However, contemporary performance evaluations on modern hardware present a different narrative. Research into GPU-accelerated hash operations, specifically the HI-SM3 framework, shows that SM3 can achieve remarkable throughput when parallelism is properly leveraged. On high-end NVIDIA hardware, SM3 has reached peak performance of 454.74 GB/s, outperforming server-class CPUs by over 150 times.11 Even on lower-power embedded GPUs, SM3 has demonstrated a throughput of 5.90 GB/s.11 This suggests that the complexity of the SM3 compression function is well-suited for high-throughput environments such as blockchain validation and large-scale data integrity verification, where GPU offloading is available.7

The SM4 Block Cipher: Robustness and Symmetric Efficiency

SM4 (formerly SMS4) is the first commercial block cipher published by the Chinese State Cryptography Administration in 2006.2 It operates on 128-bit blocks using a 128-bit key, positioning it as the primary alternative to AES-128.2 Unlike the Substitution-Permutation Network (SPN) structure of AES, SM4 utilizes an unbalanced Feistel structure, where the encryption and decryption processes are identical, differing only in the sequence of round keys.2

Round Function and Key Schedule

The SM4 algorithm consists of 32 identical rounds. Each round takes four 32-bit words as input and uses a round key to produce a new word.14 The round function involves a nonlinear substitution step (S-box) and a linear transformation .2

The substitution function is defined by:

where is the nonlinear S-box transformation, applying four independent 8-bit S-boxes in parallel.16 The S-box is constructed via a multiplicative inverse over the finite field , followed by an affine transformation.2

A critical advantage of the Feistel structure in SM4 is the elimination of the need for an inverse S-box during decryption.16 In AES, hardware implementations must account for both the S-box and its inverse, increasing gate counts.16 SM4’s symmetric round structure allows for more compact hardware designs, which is particularly beneficial for resource-constrained IoT devices and smart cards.2

Algebraic Attack Resistance

One of the most compelling arguments for SM4’s superiority in certain security contexts is its resistance to algebraic attacks. Studies comparing the computational complexities of algebraic attacks (such as the XL algorithm) against SM4 and AES suggest that SM4 is significantly more robust.20 This robustness is derived from the complexity of its key schedule and the overdefined systems of quadratic equations it produces. 20

AlgorithmKey VariablesIntermediate VariablesEqns (Enc)Eqns (Key)Complexity
AES320128089602240 (Baseline)
SM41024102471687168Higher than AES

The SM4 key schedule utilises nonlinear word rotations and S-box lookups, creating a highly complex relationship between the master key and the round keys.16 This makes the system of equations representing the cipher more difficult to solve than the relatively linear key expansion used in AES-128.20

SM2 and the Parallelism of Elliptic Curve Standards

Asymmetric cryptography is essential for key exchange and digital signatures. The SM2 standard is an elliptic curve cryptosystem (ECC) based on 256-bit prime fields, authorized for core, ordinary, and commercial use in China.21 While Western systems often default to NIST P-256 (secp256r1), SM2 provides a state-verified alternative that addresses concerns regarding parameter generation and “backdoor” potential in special-form curves.22

Curve Parameters and Design Philosophies

NIST curves are designed for maximum efficiency, utilizing quasi-Mersenne primes that facilitate fast modular reduction.26 However, the method used to select NIST parameters has faced criticism for a lack of transparency, leading to the development of “random” curves like the Brainpool series, which prioritize verifiable randomness at the cost of performance.25

SM2 occupies a strategic middle ground. It recommends a specific 256-bit curve but follows a design philosophy that aligns with the need for national security verification.22

ParameterSM2 (GB/T 32918.1-2016)NIST P-256 (FIPS 186-4)
p0xFFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFF2^256 – 2^224 + 2^192 + 2^96 – 1
a0xFFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFCp – 3
b0x28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93(Pseudo-random seed derivative)
n0xFFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 7203DF6B 21C6052B 53BBF409 39D54123(Prime order of base point)
h11

The performance of SM2 is highly competitive with ECDSA. In optimised 8-bit implementations, SM2 scalar multiplication has set speed records, outperforming even the NIST P-192 curve in certain conditions.19 Against the traditional RSA algorithm, SM2 offers a significant efficiency gain; a 256-bit SM2 key provides security equivalent to a 3072-bit RSA key while requiring far less computational power for key generation and signature operations.21

Verification and Trust in ECC

The core of the “better option” argument for SM2 lies in trust and diversity. If a vulnerability were discovered in the specific mathematical form of NIST-recommended curves, the entire global financial and communication infrastructure could be at risk.24 By maintaining an independent, state-verified standard, the Guomi suite ensures cryptographic diversity, preventing a single point of failure in the global security ecosystem.32 This is particularly relevant as the community evaluates “nothing-up-my-sleeve” numbers; SM2 provides a layer of assurance for those who prefer an alternative to NIST-vetted parameters. 22

Security Metrics: Keyspace, Work Factor, and Cover Time

The strength of any cryptographic system is measured not only by its mathematical complexity but also by its practical resistance to brute-force and analytical attacks over time. Three key concepts are central to this evaluation: keyspace, work factor, and cover time.

Keyspace and Brute-Force Resilience

The keyspace of SM4 is , which is identical to AES-128.2 In today’s computational environment, cracking a 128-bit key through brute force is infeasible, requiring trillions of years on the most powerful existing supercomputers.35 While AES-256 offers a larger keyspace, the 128-bit security level remains the global benchmark for standard commercial encryption.35

SM3, with its 256-bit output, provides a security margin of 128 bits against collision attacks, which is equivalent to SHA-256.37 The “work factor”—the estimate of effort or time needed for an adversary to overcome a protective measure—is a function of this keyspace and the specific algorithmic efficiency of the attack method.39

The Critical Dimension of Cover Time

“Cover time” refers to the duration for which a plaintext must be kept secret.41 This metric is vital because all ciphers (excluding one-time pads) are theoretically breakable given enough time and energy.43

  • Tactical Cover Time: For time-critical data, such as a command to launch a missile, the cover time might only be a few minutes. If an algorithm protects the data for an hour, it is sufficient. 42
  • Strategic Cover Time: For financial records or diplomatic communications, the cover time may be 6 years or more.44

The concept of cover time is now being re-evaluated through the lens of “Harvest Now, Decrypt Later” (HNDL).33 Adversaries are currently collecting encrypted traffic with the intention of decrypting it once cryptographically relevant quantum computers (CRQC) arrive, a date often referred to as “Q-Day”.33 If the cover time of a piece of data exceeds the time remaining until Q-Day, that data is already effectively compromised if intercepted today.45The SM-series algorithms contribute to a longer cover time by providing resistance to classical analytical breakthroughs. Because SM3 and SM4 possess distinct internal designs from the MD4/MD5 lineage and SPN-based ciphers, they offer a hedge against “all-eggs-in-one-basket” scenarios where a new mathematical attack might break one family of algorithms but not another. 32

The Geopolitics of Independent Cryptographic Standards

The development of the Guomi suite is a manifestation of “Cryptographic Sovereignty”—a nation’s ability to govern, secure, and assert authority over its digital environment without overreliance on foreign technology.47 This move is motivated by the desire for technological autonomy and the belief that commercial readiness should precede international policy enforcement.32

Sovereignty versus Autonomy

In the context of modern state power, digital sovereignty extends beyond physical borders into the informational domain.48 For many nations, relying on the encryption standards of a geopolitical rival is seen as a strategic vulnerability. The 2013 revelations regarding NIST standards and potential backdoors served as a wake-up call, accelerating the global drive toward national encryption algorithms.1

  • Chinese Context: The 2020 Cryptography Law of the People’s Republic of China distinguishes between core, ordinary, and commercial cryptography.15 It mandates the use of SM-series algorithms for critical information infrastructure and commercial data, ensuring that national algorithms protect national secrets.47

Global Impact: This mandate has fundamentally impacted global supply chains. Multinational entities operating in China must implement TLS 1.3 with SM2, SM3, and SM4 to remain compliant with the Multi-Level Protection Scheme (MLPS 2.0).4 Utilising a Western-only platform secured by AES-256 is, from a legal standpoint in that jurisdiction, equivalent to submitting an unsigned document.47

Strategic Diversity in the Post-Quantum Era

The impulse toward digital sovereignty is often equated with control, but from a technical perspective, it is a project of “thick autonomy”.50 By diversifying the algorithmic landscape, the international community becomes more resilient to systemic risks.32 If a major breakthrough were to compromise lattice-based post-quantum schemes, the existence of alternative code-based or hash-based sovereign standards would provide a vital safety net.32

This drive for independence is not unique to China. Countries like Indonesia and various European states are increasingly exploring “indigenous algorithm design” and “sovereign cryptographic systems” to ensure long-term digital independence.48 The goal is not to isolate but to ensure that the “invisible backbone” of the digital economy, cryptography, is not entirely dependent on a single geopolitical actor.33

Implementation and TLS 1.3 Integration

The practical viability of the Guomi suite is demonstrated by its integration into standard internet protocols. RFC 8998 provides the specification for using SM2, SM3, and SM4 within the TLS 1.3 framework.4 This is critical for ensuring that high-security products can maintain interoperability while meeting national security requirements.3

TLS 1.3 Cipher Suites

RFC 8998 defines two primary cipher suites that utilize the Guomi algorithms to fulfill the confidentiality and authenticity requirements of TLS 1.3:

  1. TLS_SM4_GCM_SM3 (0x00, 0xC6)
  2. TLS_SM4_CCM_SM3 (0x00, 0xC7) 4

These suites use SM4 in either Galois/Counter Mode (GCM) or Counter with CBC-MAC (CCM) mode to provide Authenticated Encryption with Associated Data (AEAD).4

FeatureAEAD_SM4_GCMAEAD_SM4_CCM
Key Length16 octets (128 bits)16 octets (128 bits)
Nonce/IV Length12 octets12 octets
Authentication Tag16 octets16 octets
Max Plaintext octets octets

The choice between GCM and CCM often depends on the underlying hardware; GCM is widely preferred for its high-speed parallel processing capabilities, whereas CCM is often utilised in wireless standards like WAPI where resource constraints are more acute.2

Hardware and Software Ecosystem

A robust ecosystem has emerged to support the Guomi suite. The primary open-source implementation is GmSSL, a fork of OpenSSL specifically optimized for SM algorithms.2 In terms of hardware, support has expanded significantly:

  • Intel: Processors starting from Arrow Lake S, Lunar Lake, and Diamond Rapids include native SM4 support.2
  • ARM: The ARMv8.4-A expansion includes dedicated SM4 instructions.2
  • RISC-V: The Zksed extension for RISC-V, ratified in 2021, provides ratified support for SM4.2

This hardware integration is crucial for narrowing the performance gap between SM4 and AES-128. Specialised ISA extensions can reduce the instruction count for an SM4 step to just 6.5 arithmetic instructions, making it a highly efficient choice for high-speed TLS communication and secure storage in mobile devices.16

Hands-on Primer: Implementing Guomi Locally

To truly appreciate the technical nuances of the Guomi suite, it is essential to move beyond the theoretical and experiment with these algorithms in a controlled environment. Most modern systems can support Guomi implementation through two primary channels: the GmSSL command-line toolkit and high-level Python libraries.

Command-Line Walkthrough: GmSSL and OpenSSL

The standard tool for interacting with SM algorithms is GmSSL, an open-source project that implements SM2, SM3, and SM4. While standard OpenSSL has added support for these algorithms, GmSSL remains the reference implementation for developers seeking the full range of national standards.

  1. SM2 Key Generation:
    Generating an SM2 private key results in an ASN.1 structured file (often .sm2 or .pem).
    Bash
    # Generate a private key
    gmssl sm2 -genkey -out private_key.pem
    # Derive the public key (the (x, y) coordinates of point Q)
    gmssl sm2 -pubout -in private_key.pem -out public_key.pem
  2. SM3 Hashing:
    Hash a file to verify its integrity, equivalent to a 256-bit “digital fingerprint.”
    Bash
    gmssl sm3 <your_file.txt>

3. SM4 Symmetric Encryption:
Encrypt a file using SM4 in CBC mode, which requires a 128-bit key and an initialisation vector (IV).
Bash
gmssl sms4 -e -in message.txt -out message.enc

Python Code Walkthrough: pygmssl

For developers building applications, Python provides straightforward wrappers such as pygmssl that abstract the complexity of C-based implementations.

Step 1: Environment Setup

Install the library via pip:

Bash

pip install pygmssl

Step 2: Hashing with SM3

The library requires input data to be formatted as bytes. Strings must be encoded before processing.

Python

from pygmssl.sm3 import SM3

data = b"hello, world"
# Compute hash in a single call
print(f"SM3 Hash: {SM3(data).hexdigest()}")

# Or hash by part for streaming data
s3 = SM3()
s3.update(b"hello, ")
s3.update(b"world")
print(f"Streaming Hash: {s3.hexdigest()}")

Step 3: Symmetric Encryption with SM4

SM4 operates on 128-bit blocks, making it highly efficient for bulk data encryption when used in modes like CBC.

Python

from pygmssl.sm4 import SM4, MOD

# Key and IV must be 16 bytes (128 bits)
key = b'0123456789abcdef'
iv = b'fedcba9876543210'

cipher = SM4(key, mode=MOD.CBC, iv=iv)
plaintext = b"sensitive data"

# The library handles padding (typically PKCS7) automatically
ciphertext = cipher.encrypt(plaintext)
decrypted = cipher.decrypt(ciphertext)

assert plaintext == decrypted

Step 4: Asymmetric Identity with SM2

SM2 can be used to generate key pairs and sign messages, proving possession of a private key without disclosing it.

Python

from pygmssl.sm2 import SM2

# Generate a new pair: 32-byte private key, 64-byte public key (x,y)
s2 = SM2.generate_new_pair()
print(f"Private Key: {s2.pri_key.hex()}")
print(f"Public Key: {s2.pub_key.hex()}")

This hands-on accessibility ensures that organisations can test for “crypto-agility” and compatibility within their local development cycles before committing to regional deployments.

Strategic Option

The determination of whether an encryption standard is “better” is contextual. When evaluated against the requirements of the modern geopolitical and technical era, the Guomi suite offers several unique advantages over the exclusive use of Western standards.

Diversity as a Defense Strategy

Systemic risk reduction is perhaps the strongest technical argument for adopting SM3 and SM4 alongside traditional standards.32 A “monoculture” in cryptography—where everyone uses the same NIST curves and SHA-2 functions—is a security vulnerability.32 A breakthrough against one design would leave the global economy exposed.33 The Guomi suite provides a separate mathematical lineage, ensuring that the digital landscape remains resilient even if unforeseen vulnerabilities are found in SPN-based ciphers or specific ECC parameter sets.32

Computational and Algebraic Superiority

  • Hashing Efficiency: While SHA-256 remains the global baseline, SM3’s structural design is highly optimized for GPU parallelism, making it a “better” option for emerging high-throughput applications like distributed ledgers and real-time data integrity audits.7
  • Symmetric Robustness: SM4’s Feistel structure offers a more compact hardware profile than AES and exhibits greater resistance to algebraic attacks, which are a primary concern in the era of advanced analytical cryptanalysis.16
  • Asymmetric Versatility: SM2 offers a state-vetted alternative to NIST curves, avoiding the “black box” controversies that have plagued Western ECC while providing a significant performance leap over legacy RSA systems.21

Navigating the Geopolitical Reality

From a strategic standpoint, an independent encryption standard is a prerequisite for state autonomy.48 For organisations operating globally, “crypto-agility”, he ability to support both NIST and Guomi suites is no longer optional; it is a regulatory and commercial necessity.34 The transition to sovereign standards ensures that the “cover time” of sensitive data is protected not just by the length of a key, but by the independence of the verification process and the diversity of the underlying mathematics. 32 As we approach the quantum era and the potential of “Q-Day,” the maturity of the Guomi suite provides a vital fallback. Its international standardisation and robust hardware support signify that China’s recommended algorithms have transitioned from a regional requirement to a foundational element of the global secure communication framework. The case for SM3 and SM4 is not one of replacing existing standards, but of expanding the arsenal of cryptographic tools available to defend the integrity and confidentiality of the world’s digital infrastructure.32

References & Further Reading:

  1. SM4 modes: CBC, CFB, OFB, and ECB – ASecuritySite.com, accessed on April 7, 2026, https://asecuritysite.com/symmetric/symsm4
  2. SM4 (cipher) – Wikipedia, accessed on April 7, 2026, https://en.wikipedia.org/wiki/SM4_(cipher)
  3. SM3 Cryptographic Hash Algorithm in a Nutshell – Zhejiang Dahua Technology Co., Ltd., accessed on April 7, 2026, https://www.dahuasecurity.com/about-dahua/trust-center/secure-and-trust/sm3-cryptographic-hash-algorithm-in-a-nutshell
  4. RFC 8998: ShangMi (SM) Cipher Suites for TLS 1.3, accessed on April 7, 2026, https://www.rfc-editor.org/rfc/rfc8998.html
  5. SM3 (hash function) – Wikipedia, accessed on April 7, 2026, https://en.wikipedia.org/wiki/SM3_(hash_function)
  6. draft-sca-cfrg-sm3-01 – The SM3 Cryptographic Hash Function – IETF Datatracker, accessed on April 7, 2026, https://datatracker.ietf.org/doc/draft-sca-cfrg-sm3/01/
  7. SHA3-256 vs SM3 | Compare Top Cryptographic Hashing Algorithms – MojoAuth, accessed on April 7, 2026, https://mojoauth.com/compare-hashing-algorithms/sha3-256-vs-sm3
  8. On the Design and Performance of Chinese OSCCA-approved Cryptographic Algorithms – BTH, accessed on April 7, 2026, https://bth.diva-portal.org/smash/get/diva2:1444129/FULLTEXT01.pdf
  9. On the Design and Performance of Chinese OSCCA-approved …, accessed on April 7, 2026, https://www.researchgate.net/publication/342996423_On_the_Design_and_Performance_of_Chinese_OSCCA-approved_Cryptographic_Algorithms
  10. on the design and performance of chinese oscca-approved cryptographic algorithms | promis, accessed on April 7, 2026, https://promisedu.se/wp-content/uploads/2020/07/ilie2020-design_and_performance_of_chinese_cryptographic_algorithms.pdf
  11. HI-SM3: High-Performance Implementation of SM3 Hash Function on Heterogeneous GPUs, accessed on April 7, 2026, https://jcst.ict.ac.cn/article/cstr/32374.14.s11390-025-4285-7
  12. HMAC-SHA3-256 vs SM3 | Compare Top Cryptographic Hashing Algorithms – MojoAuth, accessed on April 7, 2026, https://mojoauth.com/compare-hashing-algorithms/hmac-sha3-256-vs-sm3
  13. View of Discussion and Optimization of AES and SM4 Encryption Algorithms, accessed on April 7, 2026, https://drpress.org/ojs/index.php/fcis/article/view/30618/30000
  14. Cryptography – SM4 Encryption Algorithm – TutorialsPoint, accessed on April 7, 2026, https://www.tutorialspoint.com/cryptography/cryptography_sm4_encryption_algorithm.htm
  15. Introduction to the Commercial Cryptography Scheme in China – International Cryptographic Module Conference (ICMC), accessed on April 7, 2026, https://icmconference.org/wp-content/uploads/C23Introduction-on-the-Commercial-Cryptography-Scheme-in-China-20151105.pdf
  16. A Lightweight ISA Extension for AES and SM4 – arXiv, accessed on April 7, 2026, https://arxiv.org/pdf/2002.07041
  17. A Secure and Efficient White-Box Implementation of SM4 – PMC, accessed on April 7, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC11764595/
  18. AES S-box as simple algebraic transformation – Math Stack Exchange, accessed on April 7, 2026, https://math.stackexchange.com/questions/4948050/aes-s-box-as-simple-algebraic-transformation
  19. Lightweight Implementations of NIST P-256 and SM2 ECC on 8-bit Resource-Constraint Embedded Device | Request PDF – ResearchGate, accessed on April 7, 2026, https://www.researchgate.net/publication/332339930_Lightweight_Implementations_of_NIST_P-256_and_SM2_ECC_on_8-bit_Resource-Constraint_Embedded_Device
  20. Algebraic attack to SMS4 and the comparison with AES – ResearchGate, accessed on April 7, 2026, https://www.researchgate.net/publication/220793576_Algebraic_attack_to_SMS4_and_the_comparison_with_AES
  21. What Makes SM2 Encryption Special? China’s Recommended …, accessed on April 7, 2026, https://nocturnalknight.co/what-makes-sm2-encryption-special-chinas-recommended-algorithm/
  22. oscca sm2 – DiSSECT, accessed on April 7, 2026, https://dissect.crocs.fi.muni.cz/standards/oscca
  23. rfc-crypto-sm2/sections/03-sm2.md at master – GitHub, accessed on April 7, 2026, https://github.com/riboseinc/rfc-crypto-sm2/blob/master/sections/03-sm2.md
  24. RFC 9563 – » RFC Editor, accessed on April 7, 2026, https://www.rfc-editor.org/rfc/rfc9563.txt
  25. Why I don’t Trust NIST P-256 | Credelius, accessed on April 7, 2026, https://credelius.com/credelius/?p=97
  26. Elliptic curve performance: NIST vs. Brainpool – Mbed TLS documentation – Read the Docs, accessed on April 7, 2026, https://mbed-tls.readthedocs.io/en/latest/kb/cryptography/elliptic-curve-performance-nist-vs-brainpool/
  27. SafeCurves: Introduction, accessed on April 7, 2026, https://safecurves.cr.yp.to/
  28. SM2 – Standard curve database, accessed on April 7, 2026, https://std.neuromancer.sk/oscaa/SM2/
  29. Public Key cryptographic algorithm SM2 based on elliptic curves Part 5: Parameter definition, accessed on April 7, 2026, http://www.gmbz.org.cn/upload/2018-07-24/1532401863206085511.pdf
  30. Lightweight Implementations of NIST P-256 and SM2 ECC on 8-bit Resource-Constraint Embedded Device | Semantic Scholar, accessed on April 7, 2026, https://www.semanticscholar.org/paper/Lightweight-Implementations-of-NIST-P-256-and-SM2-Zhou-Su/40b68e5dc8f777530cdd49f08d0d6abc23204baa
  31. Enhancing security in instant messaging systems with a hybrid SM2, SM3, and SM4 encryption framework – PMC, accessed on April 7, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC12435676/
  32. cryptography – Nocturnalknight’s Lair, accessed on April 7, 2026, https://nocturnalknight.co/category/information-security/cryptography/
  33. Implementation of Quantum Safe Ecosystem in India – Department Of Science & Technology, accessed on April 7, 2026, https://dst.gov.in/sites/default/files/Report_TaskForce_PQMigration_4Feb26%20%28v1%29.pdf
  34. Post Quantum Cryptography – Nocturnalknight’s Lair, accessed on April 7, 2026, https://nocturnalknight.co/category/post-quantum-cryptography/
  35. AES-128 Vs AES-256 : Real-World Differences (Speed, HW Accel, Risk) – Newsoftwares.net, accessed on April 7, 2026, https://www.newsoftwares.net/blog/aes-128-vs-aes-256-real-world-differences/
  36. AES-256 vs AES-128: Head to Head – Symlex VPN, accessed on April 7, 2026, https://symlexvpn.com/difference-between-256-and-128/
  37. I’m writing a high school essay comparing SHA-3 and SHA-2. Need some help on what kind of experimentation i can do to compare them : r/cryptography – Reddit, accessed on April 7, 2026, https://www.reddit.com/r/cryptography/comments/pt7qon/im_writing_a_high_school_essay_comparing_sha3_and/
  38. Choosing a hash function for 2030 and beyond: SHA-2 vs SHA-3 vs BLAKE3, accessed on April 7, 2026, https://kerkour.com/fast-secure-hash-function-sha256-sha512-sha3-blake3
  39. New bounds for randomized busing | Request PDF – ResearchGate, accessed on April 7, 2026, https://www.researchgate.net/publication/222550333_New_bounds_for_randomized_busing
  40. Elsevier’s Dictionary of Information Security – PDF Free Download – epdf.pub, accessed on April 7, 2026, https://epdf.pub/elseviers-dictionary-of-information-security.html
  41. Topics in Algebra: Cryptography, accessed on April 7, 2026, https://www.mat.univie.ac.at/~gagt/crypto2019/C1.pdf
  42. Implementing Cryptography – CGISecurity.com, accessed on April 7, 2026, https://www.cgisecurity.com/owasp/html/ch13s06.html
  43. cryptography | Atmel | Bits & Pieces – WordPress.com, accessed on April 7, 2026, https://atmelcorporation.wordpress.com/tag/cryptography/
  44. ECS655U Security Engineering – Shona QMUL – WordPress.com, accessed on April 7, 2026, https://shonaqmul.wordpress.com/category/modules/year-3/year-3-semester-b/ecs655u-security-engineering/
  45. The State of Post-Quantum Cryptography (PQC) on the Web | F5 Labs, accessed on April 7, 2026, https://www.f5.com/labs/articles/the-state-of-pqc-on-the-web
  46. What is the difference between SHA-3 and SHA-256? – Cryptography Stack Exchange, accessed on April 7, 2026, https://crypto.stackexchange.com/questions/68307/what-is-the-difference-between-sha-3-and-sha-256
  47. What Cryptographic Algorithms Are Mandated for Remote Interpretation Data in China?, accessed on April 7, 2026, https://translate.hicom-asia.com/question/what-cryptographic-algorithms-are-mandated-for-remote-interpretation-data-in-china/
  48. Information Security and Digital Sovereignty: A Cyber–Crypto–Signal Defense Model for Indonesia – ResearchGate, accessed on April 7, 2026, https://www.researchgate.net/publication/399768275_Information_Security_and_Digital_Sovereignty_A_Cyber-Crypto-Signal_Defense_Model_for_Indonesia
  49. Cryptography Law: OSCCA Seeks Public Comments on the Cryptography Law | China Law Vision, accessed on April 7, 2026, https://www.chinalawvision.com/2017/05/intellectual-property/cryptography-law-oscca-seeks-public-comments-on-the-cryptography-law/
  50. Thin sovereignty, thick autonomy – Binding Hook, accessed on April 7, 2026, https://bindinghook.com/thin-sovereignty-thick-autonomy/
  51. RFC 8998 – ShangMi (SM) Cipher Suites for TLS 1.3 – IETF Datatracker, accessed on April 7, 2026, https://datatracker.ietf.org/doc/html/rfc8998
The Asymmetric Frontier: A Strategic Analysis of Iranian Cyber Operations and Geopolitical Resilience in the 2026 Conflict

The Asymmetric Frontier: A Strategic Analysis of Iranian Cyber Operations and Geopolitical Resilience in the 2026 Conflict

The dawn of March 2026 marks a watershed moment in the evolution of multi-domain warfare, characterised by the total integration of offensive cyber operations into high-intensity kinetic campaigns. The initiation of Operation Epic Fury by the United States and Operation Roaring Lion by the State of Israel on February 28, 2026, has provided a definitive template for the “offensive turn” in modern military doctrine.1 From a cybersecurity practitioner’s perspective, the Iranian response and the resilience of its decentralised “mosaic” architecture offer profound insights into the future of state-sponsored digital conflict. Despite the massive degradation of traditional command structures and the reported death of Supreme Leader Ayatollah Ali Khamenei, the Iranian cyber ecosystem has demonstrated an ability to maintain operational tempo through a pre-positioned proxy ecosystem that operates with significant tactical autonomy.3 This analysis examines the strategic, technical, and geopolitical dimensions of the Iranian threat, building on the observations of General James Marks and the latest assessments from the World Economic Forum (WEF), The Soufan Centre, and major global think tanks.

The Crucible of Conflict: From Strategic Patience to Operation Epic Fury

The current state of hostilities is the culmination of two distinct phases of escalation that began in mid-2025. The first phase, characterized by the “12-day war” in June 2025, saw the United States launch Operation Midnight Hammer against Iranian nuclear facilities at Fordow, Natanz, and Isfahan in response to Tehran’s expulsion of IAEA inspectors and the termination of NPT safeguards.6 During this initial encounter, the information domain was already a central battleground, with the hacker group Predatory Sparrow (Gonjeshke Darande) disrupting Iranian financial institutions and cryptocurrency exchanges to undermine domestic confidence in the regime.9 However, the second phase, initiated on February 28, 2026, represents a fundamental shift toward regime change and the total neutralization of Iran’s asymmetric capabilities.3

General James Marks, writing in The Hill, and subsequent testimony from Director of National Intelligence Tulsi Gabbard, indicate that while the Iranian government has been severely degraded, its core apparatus remains intact and capable of striking Western interests.4 This resilience is attributed to the “mosaic defense” doctrine, which the Islamic Revolutionary Guard Corps (IRGC) adopted in 2005 to survive decapitation strikes. By restructuring into 31 semi-autonomous provincial commands, the regime ensured that operational capability would persist even if the central leadership in Tehran was eliminated.3 In the cyber realm, this translates to a distributed network of APT groups and hacktivist personas that can continue to execute campaigns despite a collapse in domestic internet connectivity.2

Key Milestones in the 2025-2026 EscalationDatePrimary Operational Outcome
IAEA Safeguards TerminationFeb 10, 2026Iran expels inspectors; 60% enrichment stockpile reaches 412kg 8
Operation Midnight HammerJune 22, 2025US B-2 bombers target Fordow and Natanz 7
Initiation of Epic FuryFeb 28, 2026Joint US-Israel strikes kill Supreme Leader Khamenei 3
Electronic Operations Room FormedFeb 28, 202660+ hacktivist groups mobilize for retaliatory strikes 3
The Stryker AttackMarch 11, 2026Handala Hack wipes 200,000 devices at US medical firm 14

The Architecture of Asymmetry: Iran’s Mosaic Cyber Doctrine

The Iranian cyber program is no longer a peripheral support function but a primary tool of asymmetric leverage. The Soufan Center and RUSI emphasize that Tehran views cyber operations as a means to impose psychological costs far from the battlefield, exhausting the resources of superior foes through a war of attrition.3 This strategy relies on a “melange” of state-sponsored actors and patriotic hackers who provide the regime with plausible deniability.10

The Command Structure: IRGC and MOIS

Cyber operations are primarily distributed across two powerful organizations: the Islamic Revolutionary Guard Corps (IRGC) and the Ministry of Intelligence and Security (MOIS). The IRGC typically manages APTs focused on military targets and regional stability, such as APT33 and APT35, while the MOIS houses groups like APT34 (OilRig) and MuddyWater, which specialize in long-term espionage and infrastructure mapping.16Following the February 28 strikes, which targeted the MOIS headquarters in eastern Tehran and reportedly eliminated deputy intelligence minister Seyed Yahya Hosseini Panjaki, these units have transitioned into a state of “operational isolation”.2 This isolation has led to a surge in tactical autonomy for cells based outside of Iran, which are now acting as the regime’s primary retaliatory arm while domestic internet connectivity remains between 1% and 4% of normal levels.2

The Proxy Ecosystem and the Electronic Operations Room

A critical development in the March 2026 conflict is the formalization of the “Electronic Operations Room.” Established within 24 hours of the initial strikes, this entity serves as a centralized coordination hub for over 60 hacktivist groups, ranging from pro-regime actors to regional nationalists.13 This ecosystem allows the state to amplify its messaging and conduct large-scale disruptive operations without the immediate risk of overt attribution.3

Prominent entities within this ecosystem include:

  • Handala Hack: A persona linked to the MOIS (Void Manticore) that combines high-end destructive capabilities with propaganda.2
  • Cyber Islamic Resistance: An umbrella collective coordinating synchronized DDoS attacks against Western and Israeli infrastructure.2
  • FAD Team (Fatimiyoun Cyber Team): A group specializing in wiper malware and the permanent destruction of industrial control systems (ICS).2

Sylhet Gang: A recruitment and message-amplification engine focused on targeting Saudi and Gulf state management systems.2

Technical Deep Dive: The Stryker Breach and “Living-off-the-Cloud” Warfare

On March 11, 2026, the Iranian-linked group Handala (Void Manticore) executed what is considered the most significant wartime cyberattack against a U.S. commercial entity: the breach and subsequent wiping of the Stryker Corporation.3 This incident is a case study in the evolution of Iranian TTPs (Tactics, Techniques, and Procedures), moving away from custom malware toward the weaponization of legitimate cloud infrastructure.15

The Weaponization of Microsoft Intune

The Stryker attack bypassed traditional Endpoint Detection and Response (EDR) and antivirus solutions entirely by utilizing the company’s own Microsoft Intune platform to issue mass-wipe commands.15 This “Living-off-the-Cloud” (LotC) strategy began with the theft of administrative credentials through AitM (Adversary-in-the-Middle) phishing, which allowed the attackers to bypass multi-factor authentication (MFA) and capture session tokens.14

Once inside the internal Microsoft environment, the attackers used Graph API calls to target the organization’s device management tenant. Approximately 200,000 devices—including servers, managed laptops, and mobile phones across 61 countries—were wiped.8 The attackers also claimed to have exfiltrated 50 terabytes of sensitive data before executing the wipe, using the destruction of systems to mask the theft and create a catastrophic business continuity event.8

Technical Components of the Stryker WipeDescriptionPractitioner Implication
Initial Access VectorPhishing/AitM session token theftLegacy MFA is insufficient; move to FIDO2 14
Primary Platform ExploitedMicrosoft Intune (MDM)MDM is a Tier-0 asset requiring extreme isolation 22
Command ExecutionProgrammatic Graph API callsLog monitoring must include MDM activity spikes 22
Detection StatusNo malware binary detected“No malware detected” does not mean no breach 22
Economic Impact$6-8 billion market cap lossCyber risk is now a material financial solvency risk 17

Advanced Persistent Threat (APT) Evolution

The Stryker attack highlights a broader trend identified by Unit 42 and Mandiant: the convergence of state-sponsored espionage with destructive “hack-and-leak” operations. Groups like Handala Hack now operate with a sophisticated handoff model. Scarred Manticore (Storm-0861) provides initial access through long-dwell operations, which is then handed over to Void Manticore (Storm-0842) for the deployment of wipers or the execution of the MDM hijack.19

Other Iranian groups have demonstrated similar advancements:

  • APT42: Recently attributed by CISA for breaching the U.S. State Department, this group continues to refine its social engineering lures using GenAI to target high-value personnel.2
  • Serpens Constellation: Unit 42 tracks various IRGC-aligned actors under this name, noting an increased risk of wiper attacks against energy and water utilities in the U.S. and Israel.2
  • The RedAlert Phishing Campaign: Attackers delivered a malicious replica of the Israeli Home Front Command application through SMS phishing (smishing). This weaponized APK enabled mobile surveillance and data exfiltration from the devices of civilians and military personnel.2

Geopolitical Perspectives: RUSI, IDSA, and the Global Spillover

The conflict in Iran is not a localized event; it has profound implications for regional stability and global defense posture. Think tanks such as RUSI and MP-IDSA have provided critical analysis on how the “offensive turn” in U.S. cybersecurity strategy is being perceived globally and the lessons other nations are drawing from the 2026 war.

The “Offensive Turn” and its Discontents

The U.S. National Cybersecurity Strategy, released on March 6, 2026, formalizes the deployment of offensive cyber operations as a standard tool of statecraft. MP-IDSA notes that this shift moves beyond “defend forward” to the active imposition of costs on adversaries, utilizing “agentic AI” to scale disruption capabilities.1 During Operation Epic Fury, USCYBERCOM delivered “synchronised and layered effects” that blinded Iranian sensor networks prior to the kinetic strikes. This pattern confirms that cyber is now a “first-mover” asset, providing the intelligence and environment-shaping necessary for precision kinetic action.1

However, this strategy has raised concerns regarding international norms. By encouraging the private sector to adopt “active defense” (or “hack back”) and institutionalizing the use of cyber for regime change, the U.S. may be setting a precedent that adversaries will exploit.1 RUSI scholars warn that the “Great Liquidation” of the Moscow-Tehran axis has left Iran feeling it is in an existential fight, making it difficult to coerce through threats of violence alone.25

Regional Spillover and GCC Vulnerability

The conflict has rapidly expanded to target GCC member states perceived as supporting the U.S.-Israel coalition. Iranian retaliatory strikes—both kinetic and digital—have targeted energy infrastructure, ports, and data centers in the UAE, Bahrain, Qatar, Kuwait, and Saudi Arabia.3

  • Kuwait and Jordan: These nations have faced the brunt of hacktivist activity. Between February 28 and March 2, 76% of all hacktivist DDoS claims in the region targeted Kuwait, Israel, and Jordan.20
  • Maritime and Logistics: Iran has focused on disrupting logistics companies and shipping routes in the Persian Gulf, aiming to force the world to bear the economic cost of the war.3

The “Zeitenwende” for the Gulf: RUSI analysts suggest this conflict is a “warning about the effects of a Taiwan Straits War,” as the economic ripples of the Iran conflict demonstrate the fragility of global supply chains when faced with multi-domain state conflict.25

Lessons for Global Defense: The Indian Perspective

MP-IDSA has drawn specific lessons for India from the war in West Asia, focusing on the protection of the defense-industrial ecosystem. The vulnerability of static targets to unmanned systems and cyber-sabotage has led to a call for the integration of “Mission Sudarshan Chakra”—India’s planned shield and sword—to protect production hubs.17 The report emphasizes the need for:

  1. Dispersal and Hardening: Moving production nodes and reinforcing critical infrastructure with concrete capable of resisting 500-kg bombs.17
  2. Cyber-Active Air Defense: Integrating cyber defenses directly into air defense networks to prevent the “blinding” of sensors seen in the early phases of Operation Epic Fury.1
  3. Workforce Resilience: Protecting a skilled workforce that is “nearly irreplaceable in times of war” from digital harassment and kinetic strikes.17

Technological Trends and Future Threats: AI, OT, and Quantum

The 2026 threat landscape is defined by the emergence of new technologies that serve as “force multipliers” for both attackers and defenders. The World Economic Forum’s Global Cybersecurity Outlook 2026 notes that 64% of organizations are now accounting for geopolitically motivated cyberattacks, a significant increase from previous years.29

The AI Arms Race

AI has become a core component of the cyber-kinetic integration in 2026. Iranian actors are using GenAI to scale influence operations, spreading disinformation about U.S. casualties and false claims of successful retaliatory strikes against the Navy.30 Simultaneously, the U.S. and Israel have blurred ethical lines by using AI to assist in targeting and to accelerate the “offensive turn” in cyberspace.1

The rise of “agentic AI”—autonomous agents capable of planning and executing cyber operations—presents a double-edged sword. While it allows defenders to scale network monitoring, it also compresses the attack lifecycle. In 2025, exfiltration speeds for the fastest attacks quadrupled due to AI-enabled tradecraft.32

Operational Technology (OT) and the Visibility Gap

Unit 42 research highlights a staggering 332% year-over-year increase in internet-exposed OT devices.24 This exposure is a primary target for Iranian groups like the Fatimiyoun Cyber Team, which target SCADA and PLC systems to cause physical damage.2 The integration of IT, OT, and IoT for visibility has unintentionally created pathways for attackers to move from the corporate cloud (as seen in the Stryker attack) into the industrial control layer.13

The Quantum Imperative

As the world transitions through 2026, the progress of quantum computing is prompting an urgent shift toward quantum-safe cryptography. IDSA reports suggest that organizations slow to adapt will find themselves exposed to “harvest now, decrypt later” strategies, where state actors exfiltrate encrypted data today to be decrypted once quantum systems reach maturity.11

2026 Technological TrendsImpact on Iranian Cyber StrategyDefensive Priority
Agentic AIScaling of disruption and influence missionsAutomated, AI-driven SOC response 1
OT ConnectivityIncreased targeting of water and energy SCADAHardened segmentation; OT-SOC framework 24
Quantum Computing“Harvest now, decrypt later” espionageImplementation of post-quantum algorithms 11
Living-off-the-CloudWeaponization of MDM (Intune)Identity-first security; Zero Trust 22

Strategic Recommendations for Cybersecurity Practitioners

The Iranian threat in 2026 requires a departure from traditional, perimeter-based security models. Practitioners must adopt a mindset of “Intelligence-Driven Active Defense” to survive a persistent state-sponsored adversary.24

1. Identity-First Security and Zero Trust

The Stryker breach proves that identity is the new perimeter. Organizations must eliminate “standing privileges” and move toward an environment where administrative access is provided only when needed and strictly verified.24

  • FIDO2 MFA: Move beyond push-based notifications to phishing-resistant hardware keys.15
  • MDM Isolation: Secure Intune and other MDM platforms as Tier-0 assets. Implement “out-of-band” verification for mass-wipe or retire commands.2

2. Resilience and Data Integrity

In a conflict characterized by wiper malware, backups are a primary target.

  • Air-Gapped Backups: Maintain at least one copy of critical data offline and air-gapped to prevent the deletion of network-stored backups.2
  • Incident Response Readiness: Shift from “if” to “when.” Rehearse response motions specifically for LotC attacks where no malware is detected.15

3. Geopolitical Risk Management

Organizations must recognize that their security posture is inextricably linked to their geographical and geopolitical footprint.6

  • Supply Chain Exposure: Monitor for disruptions in shipping, energy, and regional services that could lead to “operational shortcuts” and increased vulnerability.6

Geographic IP Blocking: Consider blocking IP addresses from high-risk regions where legitimate business is not conducted to reduce the attack surface.2

Conclusion: Toward a Permanent State of Hybridity

The conflict of 2026 has demonstrated that cyber is no longer a silent “shadow war” but a foundational pillar of modern conflict. The Iranian “mosaic” has proven remarkably resilient, adapting to the death of the Supreme Leader and the degradation of its physical infrastructure by empowering a decentralized network of proxies and leveraging the vulnerabilities of the global cloud.3

For the cybersecurity practitioner, the lessons of March 2026 are clear: the era of protecting against “malware” is over; the new challenge is protecting the identity and the infrastructure that manages the digital estate.15 As General Marks and the reports from WEF and The Soufan Center indicate, the Iranian regime will continue to use cyber as its primary asymmetric leverage for years to come.3 Success in this environment requires a synthesis of technical excellence, geopolitical foresight, and an unwavering commitment to the principles of Zero Trust. The frontier of this conflict is no longer in the streets of Tehran or the deserts of the Middle East; it is in the administrative consoles of the world’s global enterprises.

References and Further Reading

  1. Beyond Defence: The Offensive Turn in US Cybersecurity Strategy – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/comments/beyond-defence-the-offensive-turn-in-us-cybersecurity-strategy
  2. Threat Brief: March 2026 Escalation of Cyber Risk Related to Iran – Unit 42, accessed on March 21, 2026, https://unit42.paloaltonetworks.com/iranian-cyberattacks-2026/
  3. Cyber Operations as Iran’s Asymmetric Leverage – The Soufan Center, accessed on March 21, 2026, https://thesoufancenter.org/intelbrief-2026-march-17/
  4. Iran’s government degraded but appears intact, top US spy says, accessed on March 21, 2026, https://www.tbsnews.net/world/irans-government-degraded-appears-intact-top-us-spy-says-1390421
  5. Threat Advisory: Iran-Aligned Cyber Actors Respond to Operation Epic Fury – BeyondTrust, accessed on March 21, 2026, https://www.beyondtrust.com/blog/entry/threat-advisory-operation-epic-fury
  6. Iran Cyber Threat 2026: What SMBs and MSPs Need to Know | Todyl, accessed on March 21, 2026, https://www.todyl.com/blog/iran-conflict-cyber-threat-smb-msp-risk
  7. The Israel–Iran War and the Nuclear Factor – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/issuebrief/the-israel-iran-war-and-the-nuclear-factor
  8. Threat Intelligence Report March 10 to March 16, 2026, accessed on March 21, 2026, https://redpiranha.net/news/threat-intelligence-report-march-10-march-16-2026
  9. The Invisible Battlefield: Information Operations in the 12-Day Israel–Iran War – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/issuebrief/the-invisible-battlefield-information-operations-in-the-12-day-israel-iran-war
  10. Fog, Proxies and Uncertainty: Cyber in US-Israeli Operations in Iran …, accessed on March 21, 2026, https://www.rusi.org/explore-our-research/publications/commentary/fog-proxies-and-uncertainty-cyber-us-israeli-operations-iran
  11. CyberSecurity Centre of Excellence – IDSA, accessed on March 21, 2026, https://idsa.in/wp-content/uploads/2026/02/ICCOE_Report_2025.pdf
  12. Cyber Command disrupted Iranian comms, sensors, top general says, accessed on March 21, 2026, https://therecord.media/iran-cyber-us-command-attack
  13. Cyber Threat Advisory on Middle East Conflict – Data Security Council of India (DSCI), accessed on March 21, 2026, https://www.dsci.in/files/content/advisory/2026/cyber_threat_advisory-middle_east_conflict.pdf
  14. The New Battlefield: How Iran’s Handala Group Crippled Stryker Corporation – Thrive, accessed on March 21, 2026, https://thrivenextgen.com/the-new-battlefield-how-irans-handala-group-crippled-stryker-corporation/
  15. intel-Hub | Critical Start, accessed on March 21, 2026, https://www.criticalstart.com/intel-hub
  16. Beyond Hacktivism: Iran’s Coordinated Cyber Threat Landscape …, accessed on March 21, 2026, https://www.csis.org/blogs/strategic-technologies-blog/beyond-hacktivism-irans-coordinated-cyber-threat-landscape
  17. Cyber Operations in the Israel–US Conflict with Iran – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/comments/cyber-operations-in-the-israel-us-conflict-with-iran
  18. Iran Readied Cyberattack Capabilities for Response Prior to Epic Fury – SecurityWeek, accessed on March 21, 2026, https://www.securityweek.com/iran-readied-cyberattack-capabilities-for-response-prior-to-epic-fury/
  19. Epic Fury Update: Stryker Attack Highlights Handala’s Shift from Espionage to Disruption, accessed on March 21, 2026, https://www.levelblue.com/blogs/spiderlabs-blog/epic-fury-update-stryker-attack-highlights-handalas-shift-from-espionage-to-disruption
  20. Global Surge: 149 Hacktivist DDoS Attacks Target SCADA and Critical Infrastructure Across 16 Countries After Middle East Conflict – Rescana, accessed on March 21, 2026, https://www.rescana.com/post/global-surge-149-hacktivist-ddos-attacks-target-scada-and-critical-infrastructure-across-16-countri
  21. Iran War: Kinetic, Cyber, Electronic and Psychological Warfare Convergence – Resecurity, accessed on March 21, 2026, https://www.resecurity.com/blog/article/iran-war-kinetic-cyber-electronic-and-psychological-warfare-convergence
  22. When the Wiper Is the Product: Nation-state MDM Attacks and What …, accessed on March 21, 2026, https://www.presidio.com/blogs/when-the-wiper-is-the-product-nation-state-mdm-attacks-and-what-every-enterprise-needs-to-know/
  23. Black Arrow Cyber Threat Intel Briefing 13 March 2026, accessed on March 21, 2026, https://www.blackarrowcyber.com/blog/threat-briefing-13-march-2026
  24. Unit 42 Threat Bulletin – March 2026, accessed on March 21, 2026, https://unit42.paloaltonetworks.com/threat-bulletin/march-2026/
  25. RUSI, accessed on March 21, 2026, https://www.rusi.org/
  26. Resource library search – RUSI, accessed on March 21, 2026, https://my.rusi.org/resource-library-search.html?sortBy=recent®ion=israel-and-the-occupied-palestinian-territories,middle-east-and-north-africa
  27. Threat Intelligence Snapshot: Week 10, 2026 – QuoIntelligence, accessed on March 21, 2026, https://quointelligence.eu/2026/03/threat-intelligence-snapshot-week-10-2026/
  28. Cyber threat bulletin: Iranian Cyber Threat Response to US/Israel strikes, February 2026 – Canadian Centre for Cyber Security, accessed on March 21, 2026, https://www.cyber.gc.ca/en/guidance/cyber-threat-bulletin-iranian-cyber-threat-response-usisrael-strikes-february-2026
  29. Cyber impact of conflict in the Middle East, and other cybersecurity news, accessed on March 21, 2026, https://www.weforum.org/stories/2026/03/cyber-impact-conflict-middle-east-other-cybersecurity-news-march-2026/
  30. Iran Cyber Attacks 2026: Threats, APT Tactics & How Organisations Should Respond | Ekco, accessed on March 21, 2026, https://www.ek.co/publications/iran-cyber-attacks-2026-threats-apt-tactics-how-organisations-should-respond/
  31. IDSA: Home Page – MP, accessed on March 21, 2026, https://idsa.in/
  32. 2026 Unit 42 Global Incident Response Report – RH-ISAC, accessed on March 21, 2026, https://rhisac.org/threat-intelligence/2026-unit-42-ir-report/
What is the Latest React Router Vulnerability And What Every Founder Should Know?

What is the Latest React Router Vulnerability And What Every Founder Should Know?

Today the cybersecurity world woke up to another reminder that even the tools we trust most can become security landmines. A critical vulnerability in React Router, one of the most widely-used routing libraries in modern web development, was disclosed, and the implications go far beyond the frontend codebase.

This isn’t a “just another bug.” At a CVSS 9.8 severity level, attackers can perform directory traversal through manipulated session cookies, effectively poking around your server’s filesystem if your app uses the affected session storage mechanism.

Let’s unpack why this matters for founders, CTOs, and builders responsible for secure product delivery.

What Happened?

React Router recently patched a flaw in the createFileSessionStorage() module that — under specific conditions — lets attackers read or modify files outside their intended sandbox by tampering with unsigned cookies.

Here’s the risk profile:

  • Attack vector: directory traversal via session cookies
  • Severity: Critical (9.8 CVSS)
  • Impact: Potential access to sensitive files and server state
  • Affected packages:
    • @react-router/node versions 7.0.0 — 7.9.3
    • @remix-run/deno and @remix-run/node before 2.17.2

While attackers can’t immediately dump any file on the server, they can navigate the filesystem in unintended ways and manipulate session artifacts — a serious foot in the door.

The takeaway: vulnerability isn’t constrained to toy apps. If you’re running SSR, session-based routing, or Remix integrations, this hits your stack.

Why This Is a Leadership Problem — Not Just a Dev One

As founders, we’re often tempted to treat vulnerabilities like IT ops tickets: triage it, patch it, close it. But here’s the real issue:

Risk isn’t just technical — it’s strategic.

Modern web apps are supply chains of open-source components. One shipped package version can suddenly create a path for adversaries into your server logic. And as we’ve seen with other critical bugs this year — like the “React2Shell” RCE exploited millions of times in the wild — threat actors are automated, relentless, and opportunistic.

Your roadmap priorities — performance, feature velocity, UX — don’t matter if an attacker compromises your infrastructure or exfiltrates configuration secrets. Vulnerabilities like this are business continuity issues. They impact uptime, customer trust, compliance, and ultimately — revenue.

The Broader React Ecosystem Risk

This isn’t the first time React-related tooling has made headlines:

  • The React Server Components ecosystem suffered a critical RCE vulnerability (CVE-2025-55182, aka “React2Shell”) late last year, actively exploited in the wild.
  • Multiple states and nation-linked threat groups were observed scanning for and abusing RSC flaws within hours of disclosure.

If your product stack relies on React, Remix, Next.js, or the broader JavaScript ecosystem — you’re in a high-traffic attack corridor. These libraries are ubiquitous, deeply integrated, and therefore lucrative targets.

What You Should Do Right Now

Here’s a practical, founder-friendly checklist you can action with your engineering team:

✅ 1. Patch Immediately

Update to the patched versions:

  • @react-router/node7.9.4+
  • @remix-run/deno & @remix-run/node2.17.2+

No exceptions.

🚨 2. Audit Session Handling

Review how your app uses unsigned cookies and session storage. Directory traversal flaws often succeed where path validation is assumed safe but not enforced.

🧠 3. Monitor for Suspicious Activity

Look for unusual session tokens, spikes in directory access patterns, or failed login anomalies. Early detection beats post-incident firefighting.

🛡 4. Bolster Your Dependency Management

Consider automated dependency scanners, SBOMs (Software Bill of Materials), and patch dashboards integrated into your CI/CD.

🗣 5. Educate the Team

Foundational libraries are as much a security concern as your application logic — upskill your developers to treat component updates like risk events.

Final Thought

Security isn’t a checkbox. It’s a continuous posture, especially in ecosystems like JavaScript where innovation and risk walk hand in hand.

The React Router vulnerability should be your wake-up call: your code is only as secure as the libraries you trust. Every build, every deploy, every npm install carries weight.

Patch fast, architect sensibly, monitor intelligently, not just for this bug, but for the next one that’s already being scanned on port 443.

Stay vigilant.
Your co-founder in code and risk

What Caused Cloudflare’s Big Crash? It’s Not Rust

What Caused Cloudflare’s Big Crash? It’s Not Rust

The Promise

Cloudflare’s outage did not just take down a fifth of the Internet. It exposed a truth we often avoid in engineering: complex systems rarely fail because of bad code. They fail because of the invisible assumptions we build into them.

This piece cuts past the memes, the Rust blame game and the instant hot takes to explain what actually broke, why the outrage misfired and what this incident really tells us about the fragility of Internet-scale systems.

If you are building distributed, AI-driven or mission-critical platforms, the key takeaways here will reset how you think about reliability and help you avoid walking away with exactly the wrong lesson from one of the year’s most revealing outages.

1. Setting the Stage: When a Fifth of the Internet Slowed to a Crawl

On 18 November, Cloudflare experienced one of its most significant incidents in recent years. Large parts of the world observed outages or degraded performance across services that underpin global traffic.
As always, the Internet reacted the way it knows best: outrage, memes, instant diagnosis delivered with absolute confidence.

Within minutes, social timelines flooded with:

  • “It must be DNS”
  • “Rust is unsafe after all”
  • “This is what happens when you rewrite everything”
  • “Even Downdetector is down because Cloudflare is down”
  • Screenshots of broken CSS on Cloudflare’s own status page
  • Accusations of over-engineering, under-engineering and everything in between

The world wanted a villain. Rust happened to be available. But the actual story is more nuanced and far more interesting. (For the record, I am still not convinced we should rewrite Linux kernel in Rust !)

2. What Actually Happened: A Clear Summary of Cloudflare’s Report

Cloudflare’s own post-incident write-up is unusually thorough. If you have not read it, you should. In brief:

  • Cloudflare is in the middle of a major multi-year upgrade of its edge infrastructure, referred to internally as the 20 percent Internet upgrade.
  • The rollout included a new feature configuration file.
  • This file contained more than two hundred features for their FL2 component, crossing a size limit that had been assumed but never enforced through guardrails.
  • The oversized file triggered a panic in the Rust-based logic that validated these configurations.
  • That panic initiated a restart loop across a large portion of their global fleet.
  • Because the very nodes that needed to perform a rollback were themselves in a degraded state, Cloudflare could not recover the control plane easily.
  • This created a cascading, self-reinforcing failure.
  • Only isolated regions with lagged deployments remained unaffected.

The root cause was a logic-path issue interacting with operational constraints. It had nothing to do with memory safety and nothing to do with Rust’s guarantees.

In other words: the failure was architectural, not linguistic.

3.2 The “unwrap() Is Evil” Argument (I remember writing a blog titled Eval() is not Evil() ~2012)

One of the most widely circulated tweets framed the presence of an unwrap() as a ticking time bomb, casting it as proof that Rust developers “trust themselves too much”. This is a caricature of the real issue.

The error did not arise because of an unwrap(), nor because Rust encourages poor error handling. It arose because:

  • an unexpected input crossed a limit,
  • guards were missing,
  • and the resulting failure propagated in a tightly coupled system.

The same failure would have occurred in Go, Java, C++, Zig, or Python.

3.3 Transparency Misinterpreted as Guilt

Cloudflare did something rare in our industry.
They published the exact code that failed. This was interpreted by some as:

“Here is the guilty line. Rust did it.”

In reality, Cloudflare’s openness is an example of mature engineering culture. More on that later.

4. The Internet Rage Cycle: Humour, Oversimplification and Absolute Certainty

The memes and tweets around this outage are not just entertainment. They reveal how the broader industry processes complex failure.

4.1 The ‘Everything Balances on Open Source’ Meme

Images circulated showing stacks of infrastructure teetering on boxes labelled DNS, Linux Foundation and unpaid open source developers, with Big Tech perched precariously on top.

This exaggeration contains a real truth. We live in a dependency monoculture. A few layers of open source and a handful of service providers hold up everything else.

The meme became shorthand for Internet fragility.

4.2 The ‘It Was DNS’ Routine

The classic:
“It is not DNS. It cannot be DNS. It was DNS.”

Except this time, it was not DNS.

Yet the joke resurfaces because DNS has become the folk villain for any outage. People default to the easiest mental shortcut.

4.3 The Rust Panic Narrative

Tweets claiming:

“Cloudflare rewrote in Rust, and half the Internet went down 53 days later.”

This inference is wrong, but emotionally satisfying.
People conflate correlation with causation because it creates a simple story: rewrites are dangerous.

4.4 The Irony of Downdetector Being Down

The screenshot of Downdetector depending on Cloudflare and therefore failing is both funny and revealing. This outage demonstrated how deeply intertwined modern platforms are. It is an ecosystem issue, not a Cloudflare issue.

4.5 But There Were Also Good Takes

Kelly Sommers’ observation that Cloudflare published source code is a reminder that not everyone jumped to outrage.

There were pockets of maturity. Unfortunately, they were quieter than the noise.

5. The Real Lessons for Engineering Leaders

This is the part worth reading slowly if you build distributed systems.

Lesson 1: Reliability Is an Architecture Choice, Not a Language Choice

You can build fragile systems in safe languages and robust systems in unsafe languages. Language is orthogonal to architectural resilience.

Lesson 2: Guardrails Matter More Than Guarantees

Rust gives memory safety.
It does not give correctness safety.
It does not give assumption safety.
It does not give rollout safety.

You cannot outsource judgment.

Lesson 3: Blast Radius Containment Is Everything

  • Uniform rollouts are dangerous.
  • Synchronous edge updates are dangerous.
  • Large global fleets need layered fault domains.

Cloudflare knows this. This incident will accelerate their work here.

Lesson 4: Control Planes Must Be Resilient Under Their Worst Conditions

The control plane was unreachable when it was needed most. This is a classic distributed systems trap: the emergency mechanism relies on the unhealthy components.

Always test:

  • rollback unavailability
  • degraded network conditions
  • inconsistent state recovery

Lesson 5: Complexity Fails in Complex Ways

The system behaved exactly as designed. That is the problem.
Emergent behaviour in large networks cannot be reasoned about purely through local correctness.

This is where most teams misjudge their risk.

6. Additional Lesson: Accountability and Transparency Are Strategic Advantages

This incident highlighted something deeper about Cloudflare’s culture.

They did not hide behind ambiguity.
They did not release a PR-approved statement with vague phrasing.

They published:

  • the timeline
  • the diagnosis
  • the exact code
  • the root cause
  • the systemic contributors
  • the ongoing mitigation plan

This level of transparency is uncomfortable. It puts the organisation under a microscope.
Yet it builds trust in a way no marketing claim can.

Transparency after failure is not just ethical. It is good engineering. Very few people highlighted including my man Gergely Orosz.

Most companies will never reach this level of accountability.
Cloudflare raised the bar.

7. What This Outage Tells Us About the State of the Internet

This was not a Cloudflare problem, This is a reminder of our shared dependency.

  • Too much global traffic flows through too few choke points.
  • Too many systems assume perfect availability from upstream.
  • Too many platforms synchronise their rollouts.
  • Too many companies run on infrastructure they did not build and cannot control.

The memes were not wrong.
They were simply incomplete.

8. Final Thoughts: Rust Did Not Fail. Our Assumptions Did.

Outages like this shape the future of engineering. The worst thing the industry can do is learn the wrong lesson.

This was not:

  • a Rust failure
  • a rewrite failure
  • an open source failure
  • a Cloudflare hubris story

This was a systems-thinking failure.
A reminder that assumptions are the most fragile part of any distributed system.
A demonstration of how tightly coupled global infrastructure has become.
A case study in why architecture always wins over language debates.

Cloudflare’s transparency deserves respect.
Their engineering culture deserves attention.
And the outrage cycle deserves better scepticism.

Because the Internet did not go down because of Rust.
It went down because the modern Internet is held together by coordination, trust, and layered assumptions that occasionally collide in surprising ways.

If we want a more resilient future, we need less blame and more understanding.
Less certainty and more curiosity.
Less language tribalism and more systems design thinking.

The Internet will fail again.
The question is whether we learn or react.

Cloudflare learned. The rest of us should too!

When Trust Cracks: The Vault Fault That Shook Identity Security

When Trust Cracks: The Vault Fault That Shook Identity Security

A vault exposed outside the DMZ

Opening Scene: The Unthinkable Inside Your Digital Fortress

Imagine standing before a vault that holds every secret of your organisation. It is solid, silent and built to withstand brute force. Yet, one day you discover someone walked straight in. No alarms. No credentials. No trace of a break-in. That is what the security community woke up to when researchers disclosed Vault Fault. A cluster of flaws in the very tools meant to guard our digital crown jewels.

Behind the Curtain: The Guardians of Our Secrets

Secrets management platforms like HashiCorp Vault and CyberArk Conjur or Secrets Manager sit at the heart of modern identity infrastructure. They store API keys, service credentials, encryption keys and more. In DevSecOps pipelines and hybrid environments, they are the trusted custodians. If a vault is compromised, it is not one system at risk. It is every connected system.

Vault Fault Unveiled: A Perfect Storm of Logic Flaws

Security firm Cyata revealed fourteen vulnerabilities spread across CyberArk and HashiCorp’s vault products. These were not just minor configuration oversights. They included:

  • CyberArk Conjur: IAM authenticator bypass by manipulating how regions are parsed. Privilege escalation by authenticating as a policy. Remote code execution by exploiting the ERB-based Policy Factory.
  • HashiCorp Vault: Nine zero-day issues including the first ever RCE in Vault. Bypasses of multi-factor authentication and account lockout logic. User enumeration through subtle timing differences. Escalation by abusing how policies are normalised.

These were chains of logic flaws that could be combined to devastating effect. Attackers could impersonate identities, escalate privileges, execute arbitrary code and exfiltrate secrets without ever providing valid credentials.

The Fallout: When Silent Vaults Explode

Perhaps the most unnerving fact is the age of some vulnerabilities. Several had been present for up to nine years. Quiet, undetected and exploitable. Remote code execution against a secrets vault is the equivalent of giving an intruder the keys to every door in your company. Once inside, they can lock you out, leak sensitive information or weaponise access for extortion.

Response and Remedy: Patch, Shield, Reinvent

Both vendors have issued fixes:

  • CyberArk Secrets Manager and Self-Hosted versions 13.5.1 and 13.6.1.
  • CyberArk Conjur Open Source version 1.22.1.
  • HashiCorp Vault Community and Enterprise editions 1.20.2, 1.19.8, 1.18.13 and 1.16.24.

Cyata’s guidance is direct. Patch immediately. Restrict network exposure of vault instances. Audit and rotate secrets. Minimise secret lifetime and scope. Enable detailed audit logs and monitor for anomalies. CyberArk has also engaged directly with customers to support remediation efforts.

Broader Lessons: Beyond the Fault

The nature of these flaws should make us pause. They were not memory corruption or injection bugs. They were logic vulnerabilities hiding in plain sight. The kind that slip past automated scans and live through version after version.

It is like delegating your IaaS or PaaS to AWS or Azure. They may run the infrastructure, but you are still responsible for meeting your own uptime SLAs. In the same way, even if you store secrets such as credit card numbers, API tokens or encryption keys in a vault, you remain responsible for securing them. The liability for a breach still sits with you.

Startups are especially vulnerable. Many operate under relentless deadlines and tight budgets. They offload everything that is not seen as part of their “core” operations to third parties. This speeds up delivery but also widens the blast radius when those dependencies are compromised. When your vault provider fails, your customers will still hold you accountable.

This should push us to adopt more defensive architectures. Moving towards ephemeral credentials, context-aware access and reducing reliance on long-lived static secrets.

We also need a culture shift. Secrets vaults are not infallible. Their security must be tested continuously. This includes adversarial simulations, code audits and community scrutiny. Trust in security systems is not a one-time grant. It is a relationship that must be earned repeatedly.

Closing Reflection: Trust Must Earn Itself Again

Vault Fault is a reminder that even our most trusted systems can develop cracks. The breach is not in the brute force of an attacker but in the quiet oversight of logic and design. As defenders, we must assume nothing is beyond failure. We must watch the watchers, test the guards and challenge the fortresses we build. Because the next fault may already be there, waiting to be found.

References and Further Reading

  1. The Hacker News – CyberArk and HashiCorp Flaws Enable Secret Exfiltration Without Credentials: https://thehackernews.com/2025/08/cyberark-and-hashicorp-flaws-enable.html
  2. CSO Online – Researchers uncover RCE attack chains in popular enterprise credential vaults: https://www.csoonline.com/article/4035274/researchers-uncover-rce-attack-chains-in-popular-enterprise-credential-vaults.html
  3. Dark Reading – Critical Zero-Day Bugs in CyberArk, HashiCorp Password Vaults: https://www.darkreading.com/cybersecurity-operations/critical-zero-day-bugs-cyberark-hashicorp-password-vaults
  4. Cyata Security – Vault Fault Disclosure: https://cyata.ai/vault-fault
  5. CyberArk Official Blog – Addressing Recent Vulnerabilities and Our Commitment to Security: https://www.cyberark.com/resources/all-blog-posts/addressing-recent-vulnerabilities-and-our-commitment-to-security
Oracle Cloud Breach Is a Transitive Trust Timebomb : Here’s How to Defuse It

Oracle Cloud Breach Is a Transitive Trust Timebomb : Here’s How to Defuse It

“One mispatched server in the cloud can ignite a wildfire of trust collapse across 140,000 tenants.”

1. The Context: Why This Matters

In March 2025, a breach at Oracle Cloud shook the enterprise SaaS world. A few hours after Rahul from CloudSEK first flagged signs of a possible compromise, I published an initial analysis titled Is Oracle Cloud Safe? Data Breach Allegations and What You Need to Do Now. That piece was an urgent response to a fast-moving situation, but this article is the reflective follow-up. Here, I break down not just the facts of what happened, but the deeper problem it reveals: the fragility of transitive trust in modern cloud ecosystems.

Threat actor rose87168 leaked nearly 6 million records tied to Oracle’s login infrastructure, affecting over 140,000 tenants. The source? A misconfigured legacy server still running an unpatched version of Oracle Access Manager (OAM) vulnerable to CVE‑2021‑35587.

Initially dismissed by Oracle as isolated and obsolete, the breach was later confirmed via datasets and a tampered page on the login domain itself, captured in archived snapshots. This breach was not just an Oracle problem. It was a supply chain problem. The moment authentication breaks upstream, every SaaS product, platform, and identity provider depending on it inherits the risk, often unknowingly.

Welcome to the age of transitive trust. shook the enterprise SaaS world. Threat actor rose87168 leaked nearly 6 million records tied to Oracle’s login infrastructure, affecting over 140,000 tenants. The source? A misconfigured legacy server still running an unpatched version of Oracle Access Manager (OAM) vulnerable to CVE‑2021‑35587.

Initially dismissed by Oracle as isolated and obsolete, the breach was later confirmed via datasets and a tampered page on the login domain itself, captured in archived snapshots. This breach was not just an Oracle problem. It was a supply chain problem. The moment authentication breaks upstream, every SaaS product, platform, and identity provider depending on it inherits the risk, often unknowingly.

Welcome to the age of transitive trust.

2. Anatomy of the Attack

Attack Vector

  • Exploited: CVE-2021-35587, a critical RCE in Oracle Access Manager.
  • Payload: Malformed XML allowed unauthenticated remote code execution.

Exploited Asset

  • Legacy Oracle Cloud Gen1 login endpoints still active (e.g., login.us2.oraclecloud.com).
  • These endpoints were supposedly decommissioned but remained publicly accessible.

Proof & Exfiltration

  • Uploaded artefact visible in Wayback Machine snapshots.
  • Datasets included:
    • JKS files, encrypted SSO credentials, LDAP passwords
    • Tenant metadata, PII, hashes of admin credentials

Validated by researchers from CloudSEK, ZenoX, and GoSecure.

3. How Was This Possible?

  • Infrastructure drift: Legacy systems like Gen1 login were never fully decommissioned.
  • Patch blindness: CVE‑2021‑35587 was disclosed in 2021 but remained exploitable.
  • Trust misplacement: Downstream services assumed the upstream IDP layer was hardened.
  • Lack of dependency mapping: Tenants had no visibility into Oracle’s internal infra state.

4. How This Could Have Been Prevented

Oracle’s Prevention Gaps
VectorPreventive Control
Legacy exposureEnforce infra retirement workflows. Remove public DNS entries for deprecated endpoints.
Patch gapsAutomate CVE patch enforcement across cloud services with SLA tracking.
IDP isolationDecouple prod identity from test/staging legacy infra. Enforce strict perimeter controls.
What Clients Could Have Done
Risk InheritedMitigation Strategy
Blind transitive trustMaintain a real-time trust graph between IDPs, SaaS apps, and their dependencies.
Credential overreachUse scoped tokens, auto-expire shared secrets, enforce rotation.
Detection lagMonitor downstream for leaked credentials or unusual login flows tied to upstream IDPs.

5. Your Response Plan for Upstream IDP Risk

DomainBest Practices
Identity & AccessEnforce federated MFA, short-lived sessions, conditional access rules
Secrets ManagementStore all secrets in a vault, rotate frequently, avoid static tokens
Vulnerability HygieneIntegrate CVE scanners into CI/CD pipelines and runtime checks
Visibility & AuditingMaintain structured logs of identity provider access and token usage
Trust Graph MappingActively map third-party IDP integrations, revalidate quarterly

6. Tools That Help You Defuse Transitive Trust Risks

ToolMitigatesUse Case
CloudSEK XVigilCredential leaksMonitor for exposure of tokens, admin hashes, or internal credentials in open channels
Cortex Xpanse / CensysLegacy infra exposureSurface forgotten login domains and misconfigured IDP endpoints
OPA / OSQuery / FalcoPolicy enforcementDetect violations of login logic, elevated access, or fallback misroutes
Orca / WizRuntime postureSpot residual access paths and configuration drifts post-incident
Sigstore / CosignSupply chain integrityProtect CI/CD artefacts but limited in identity-layer breach contexts
Vault (HashiCorp)Secrets lifecycleAutomate token expiration, key rotation, and zero plaintext exposure
Zerberus.ai Trace-AITransitive trust, IDP visibilityDiscover hidden dependencies in SaaS trust chains and enforce control validation

7. Lessons Learned

When I sat down to write this, these statements felt too obvious to be called lessons. Of course authentication is production infrastructure, any practitioner would agree. But then why do so few treat it that way? Why don’t we build failovers for our SSO? Why is trust still assumed, rather than validated?

These aren’t revelations. They’re reminders; hard-earned ones.

  • Transitive trust is NOT NEUTRAL, it’s a silent threat multiplier. It embeds risk invisibly into every integration.
  • Legacy infrastructure never retires itself. If it’s still reachable, it’s exploitable.
  • Authentication systems deserve production-level fault tolerance. Build them like you’d build your API or Payment Gateway.
  • Trust is not a diagram to revisit once a year; it must be observable, enforced, and continuously verified.

8. Making the Invisible Visible: Why We Built Zerberus

Transitive trust is invisible until it fails. Most teams don’t realise how many of their security guarantees hinge on external identity providers, third-party SaaS integrations, and cloud-native IAM misconfigurations.

At Zerberus, we set out to answer a hard question: What if you could see the trust relationships before they became a risk?

  • We map your entire trust graph, from identity providers and cloud resources to downstream tools and cross-SaaS entitlements.
  • We continuously verify the health and configuration of your identity and access layers, including:
    • MFA enforcement
    • Secret expiration windows
    • IDP endpoint exposure
  • We bridge compliance and security by treating auth controls and access posture as observable artefacts, not static assumptions.

Your biggest security risk may not be inside your codebase, but outside your control plane. Zerberus is your lens into that blind spot.

Further Reading & References

Want to Know Who You’re Really Trusting?

Start your free Zerberus trial and discover the trust graph behind your SaaS stack—before someone else does.

InfoSec’s Big Problem: Too Much Hope in One Cyber Database

InfoSec’s Big Problem: Too Much Hope in One Cyber Database

The Myth of a Single Cyber Superpower: Why Global Infosec Can’t Rely on One Nation’s Database

What the collapse of MITRE’s CVE funding reveals about fragility, sovereignty, and the silent geopolitics of vulnerability management

I. The Day the Coordination Engine Stalled

On April 16, 2025, MITRE’s CVE program—arguably the most critical coordination layer in global vulnerability management—lost its federal funding.

There was no press conference, no coordinated transition plan, no handover to an international body. Just a memo, and silence. As someone who’s worked in information security for two decades, I should have been surprised. I wasn’t. We’ve long been building on foundations we neither control nor fully understand.The CVE database isn’t just a spreadsheet of flaws. It is the lingua franca of cybersecurity. Without it, our systems don’t just become more vulnerable—they become incomparable.

II. From Backbone to Bottleneck

Since 1999, CVEs have given us a consistent, vendor-neutral way to identify and communicate about software vulnerabilities. Nearly every scanner, SBOM generator, security bulletin, bug bounty program, and regulatory framework references CVE IDs. The system enables prioritisation, automation, and coordinated disclosure.

But what happens when that language goes silent?

“We are flying blind in a threat-rich environment.”
Jen Easterly, former Director of CISA (2025)

That threat blindness is not hypothetical. The National Vulnerability Database (NVD)—which depends on MITRE for CVE enumeration—has a backlog exceeding 10,000 unanalysed vulnerabilities. Some tools have begun timing out or flagging stale data. Security orchestration systems misclassify vulnerabilities or ignore them entirely because the CVE ID was never issued.

This is not a minor workflow inconvenience. It’s a collapse in shared context, and it hits software supply chains the hardest.

III. Three Moves That Signalled Systemic Retreat

While many are treating the CVE shutdown as an isolated budget cut, it is in fact the third move in a larger geopolitical shift:

  • January 2025: The Cyber Safety Review Board (CSRB) was disbanded—eliminating the U.S.’s central post-incident review mechanism.
  • March 2025: Offensive cyber operations against Russia were paused by the U.S. Department of Defense, halting active containment of APTs like Fancy Bear and Gamaredon.
  • April 2025: MITRE’s CVE funding expired—effectively unplugging the vulnerability coordination layer trusted worldwide.

This is not a partisan critique. These decisions were made under a democratically elected government. But their global consequences are disproportionate. And this is the crux of the issue: when the world depends on a single nation for its digital immune system, even routine political shifts create existential risks.

IV. Global Dependency and the Quiet Cost of Centralisation

MITRE’s CVE system was always open, but never shared. It was funded domestically, operated unilaterally, and yet adopted globally.

That arrangement worked well—until it didn’t.

There is a word for this in international relations: asymmetry. In tech, we often call it technical debt. Whatever we name it, the result is the same: everyone built around a single point of failure they didn’t own or influence.

“Integrate various sources of threat intelligence in addition to the various software vulnerability/weakness databases.”
NSA, 2024

Even the NSA warned us not to over-index on CVE. But across industry, CVE/NVD remains hardcoded into compliance standards, vendor SLAs, and procurement language.

And as of this month, it’s… gone!

V. What Europe Sees That We Don’t Talk About

While the U.S. quietly pulled back, the European Union has been doing the opposite. Its Cyber Resilience Act (CRA) mandates that software vendors operating in the EU must maintain secure development practices, provide SBOMs, and handle vulnerability disclosures with rigour.

Unlike CVE, the CRA assumes no single vulnerability database will dominate. It emphasises process over platform, and mandates that organisations demonstrate control, not dependency.

This distinction matters.

If the CVE system was the shared fire alarm, the CRA is a fire drill—with decentralised protocols that work even if the main siren fails.

Europe, for all its bureaucratic delays, may have been right all along: resilience requires plurality.

VI. Lessons for the Infosec Community

At Zerberus, we anticipated this fracture. That’s why our ZSBOM™ platform was designed to pull vulnerability intelligence from multiple sources, including:

  • MITRE CVE/NVD (when available)
  • Google OSV
  • GitHub Security Advisories
  • Snyk and Sonatype databases
  • Internal threat feeds

This is not a plug; it’s a plea. Whether you use Zerberus or not, stop building your supply chain security around a single feed. Your tools, your teams, and your customers deserve more than monoculture.

VII. The Superpower Paradox

Here’s the uncomfortable truth:

When you’re the sole superpower, you don’t get to take a break.

The U.S. built the digital infrastructure the world relies on. CVE. DNS. NIST. Even the major cloud providers. But global dependency without shared governance leads to fragility.

And fragility, in cyberspace, gets exploited.

We must stop pretending that open-source equals open-governance, that centralisation equals efficiency, or that U.S. stability is guaranteed. The MITRE shutdown is not the end—but it should be a beginning.

A beginning of a post-unipolar cybersecurity infrastructure, where responsibility is distributed, resilience is engineered, and no single actor—however well-intentioned—is asked to carry the weight of the digital world.

References 

  1. Gatlan, S. (2025) ‘MITRE warns that funding for critical CVE program expires today’, BleepingComputer, 16 April. Available at: https://www.bleepingcomputer.com/news/security/mitre-warns-that-funding-for-critical-cve-program-expires-today/ (Accessed: 16 April 2025).
  2. Easterly, J. (2025) ‘Statement on CVE defunding’, Vocal Media, 15 April. Available at: https://vocal.media/theSwamp/jen-easterly-on-cve-defunding (Accessed: 16 April 2025).
  3. National Institute of Standards and Technology (NIST) (2025) NVD Dashboard. Available at: https://nvd.nist.gov/general/nvd-dashboard (Accessed: 16 April 2025).
  4. The White House (2021) Executive Order on Improving the Nation’s Cybersecurity, 12 May. Available at: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ (Accessed: 16 April 2025).
  5. U.S. National Security Agency (2024) Mitigating Software Supply Chain Risks. Available at: https://media.defense.gov/2024/Jan/30/2003370047/-1/-1/0/CSA-Mitigating-Software-Supply-Chain-Risks-2024.pdf (Accessed: 16 April 2025).
  6. European Commission (2023) Proposal for a Regulation on Cyber Resilience Act. Available at: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (Accessed: 16 April 2025).
Disbanding the CSRB: A Mistake for National Security

Disbanding the CSRB: A Mistake for National Security

Why Ending the CSRB Puts America at Risk

Imagine dismantling your fire department just because you haven’t had a major fire recently. That’s effectively what the Trump administration has done by disbanding the Cyber Safety Review Board (CSRB), a critical entity within the Cybersecurity and Infrastructure Security Agency (CISA). In an era of escalating cyber threats—ranging from ransomware targeting hospitals to sophisticated state-sponsored attacks—this decision is a catastrophic misstep for national security.

While countries across the globe are doubling down on cybersecurity investments, the United States has chosen to retreat from a proactive posture. The CSRB’s closure sends a dangerous message: that short-term political optics can override the long-term need for resilience in the face of digital threats.

The Role of the CSRB: A Beacon of Cybersecurity Leadership

Established to investigate and recommend strategies following major cyber incidents, the CSRB functioned as a hybrid think tank and task force, capable of cutting through red tape to deliver actionable insights. Its role extended beyond the public-facing reports; the board was deeply involved in guiding responses to sensitive, behind-the-scenes threats, ensuring that risks were mitigated before they escalated into crises.

The CSRB’s disbandment leaves a dangerous void in this ecosystem, weakening not only national defenses but also the trust between public and private entities.

CSRB: Championing Accountability and Reform

One of the CSRB’s most significant contributions was its ability to hold even the most powerful corporations accountable, driving reforms that prioritized security over profit. Its achievements are best understood through the lens of its high-profile investigations:

Key Milestones

Why the CSRB’s Work Mattered

The CSRB’s ability to compel change from tech giants like Microsoft underscored its importance. Without such mechanisms, corporations are less likely to prioritise cybersecurity, leaving critical infrastructure vulnerable to attack. As cyber threats grow in complexity, dismantling accountability structures like the CSRB risks fostering an environment where profits take precedence over security—a dangerous proposition for national resilience.

Cybersecurity as Strategic Deterrence

To truly grasp the implications of the CSRB’s dissolution, one must consider the broader strategic value of cybersecurity. The European Leadership Network aptly draws parallels between cyber capabilities and nuclear deterrence. Both serve as powerful tools for preventing conflict, not through their use but through the strength of their existence.

By dismantling the CSRB, the U.S. has not only weakened its ability to deter cyber adversaries but also signalled a lack of commitment to proactive defence. This retreat emboldens adversaries, from state-sponsored actors like China’s STORM-0558 to decentralized hacking groups, and undermines the nation’s strategic posture.

Global Trends: A Stark Contrast

While the U.S. retreats, the rest of the world is surging ahead. Nations in the Indo-Pacific, as highlighted by the Royal United Services Institute, are investing heavily in cybersecurity to counter growing threats. India, Japan, and Australia are fostering regional collaborations to strengthen their collective resilience.

Similarly, the UK and continental Europe are prioritising cyber capabilities. The UK, for instance, is shifting its focus from traditional nuclear deterrence to building robust cyber defences, a move advocated by the European Leadership Network. The EU’s Cybersecurity Strategy exemplifies the importance of unified, cross-border approaches to digital security.

The U.S.’s decision to disband the CSRB stands in stark contrast to these efforts, risking not only its national security but also its leadership in global cybersecurity.

Isolationism’s Dangerous Consequences

This decision reflects a broader trend of isolationism within the Trump administration. Whether it’s withdrawing from the World Health Organization or sidelining international climate agreements, the U.S. has increasingly disengaged from global efforts. In cybersecurity, this isolationist approach is particularly perilous.

Global threats demand global solutions. Initiatives like the Five Eyes’ Secure Innovation program (Infosecurity Magazine) demonstrate the value of collaborative defence strategies. By withdrawing from structures like the CSRB, the U.S. not only risks alienating allies but also forfeits its role as a global leader in cybersecurity.

The Cost of Complacency

Cybersecurity is not a field that rewards complacency. As CSO Online warns, short-term thinking in this domain can lead to long-term vulnerabilities. The absence of the CSRB means fewer opportunities to learn from incidents, fewer recommendations for systemic improvements, and a diminished ability to adapt to evolving threats.

The cost of this decision will likely manifest in increased cyber incidents, weakened critical infrastructure, and a growing divide between the U.S. and its allies in terms of cybersecurity capabilities.

Conclusion

The disbanding of the CSRB is not just a bureaucratic reshuffle—it is a strategic blunder with far-reaching implications for national and global security. In an age where digital threats are as consequential as conventional warfare, dismantling a key pillar of cybersecurity leaves the United States exposed and isolated.

The CSRB’s legacy of transparency, accountability, and reform serves as a stark reminder of what’s at stake. Its dissolution not only weakens national defences but also risks emboldening adversaries and eroding trust among international partners. To safeguard its digital future, the U.S. must urgently rebuild mechanisms like the CSRB, reestablish its leadership in cybersecurity, and recommit to collaborative defence strategies.

References & Further Reading

  1. TechCrunch. (2025). Trump administration fires members of cybersecurity review board in horribly shortsighted decision. Available at: TechCrunch
  2. The Conversation. (2025). Trump has fired a major cybersecurity investigations body – it’s a risky move. Available at: The Conversation
  3. TechDirt. (2025). Trump disbands cybersecurity board investigating massive Chinese phone system hack. Available at: TechDirt
  4. European Leadership Network. (2024). Nuclear vs Cyber Deterrence: Why the UK Should Invest More in Its Cyber Capabilities and Less in Nuclear Deterrence. Available at: ELN
  5. Royal United Services Institute. (2024). Cyber Capabilities in the Indo-Pacific: Shared Ambitions, Different Means. Available at: RUSI
  6. Infosecurity Magazine. (2024). Five Eyes Agencies Launch Startup Security Initiative. Available at: Infosecurity Magazine
  7. CSO Online. (2024). Project 2025 Could Escalate US Cybersecurity Risks, Endanger More Americans. Available at: CSO Online
Bitnami