Quantum-Safe Storage Isn’t a 2030 Problem. It’s Shipping Today.

What if the most urgent quantum-computing problem in your data center is not what happens in 2030, but the storage traffic crossing your Fibre Channel cables today? That is the architectural question behind a set of capabilities that are no longer confined to a roadmap: post-quantum cryptography (PQC) for server-to-array Fibre Channel connections, the storage fabric’s management plane, and IPsec-protected replication links.

This one is personal for me. I earned my Brocade Distinguished Architect (BDA) designation in April 2014, long before Brocade’s acquisition, and wrote a guide to that certification journey at the time. Brocade has always been near and dear to my heart, so getting to revisit the fabric through the lens of a very modern security challenge is genuinely exciting. More importantly, this is a story infrastructure architects, storage administrators, CISOs, and security operations teams should be having now.

The big picture: three parts of the storage path, three different protections

Quick take: Broadcom’s Emulex SecureHBA and compatible arrays can negotiate hardware-offloaded, PQC-protected Fibre Channel encryption at login. Brocade Fabric OS 10.x brings post-quantum algorithms to switch-management security and firmware trust. Brocade Extension adds a selectable PQC profile for IPsec over a WAN. These are complementary capabilities, not one automatic switch that makes every link quantum-safe. The hardware, software, endpoints, configuration, and verification all matter.

• Server to storage array: protect the actual storage payload in transit, using AES-256-GCM with PQC-based session establishment and authentication.
• The SAN fabric: strengthen switch administration, certificate-based communication, and trusted firmware using PQC-capable security in Fabric OS 10.x. Treat inter-switch-link protection and authentication as separate items to validate.
• Data center to data center: protect replication or extension traffic crossing external IP networks with an IPsec PQC profile on supported Brocade Extension platforms.

Why “harvest now, decrypt later” changes the deadline

There is no defensible date for when a cryptographically relevant quantum computer will become available. But adversaries do not need that date to capture traffic today. In a harvest-now, decrypt-later (HNDL) attack, an adversary collects encrypted communications now and retains them in the hope that future cryptanalytic capabilities will expose the underlying information. If the confidentiality life of that data is long—think financial records, patient information, intellectual property, research, or government information—the migration window starts before the quantum breakthrough, not after it.

PQC does not mean “use a quantum computer to encrypt data.” It means replacing vulnerable public-key operations with algorithms designed to resist known classical and quantum attacks. NIST FIPS 203 standardizes ML-KEM for establishing shared secrets; FIPS 204 standardizes ML-DSA for signatures. The storage payload can still use well-established symmetric encryption such as AES-256-GCM. That distinction—quantum-resistant key establishment and authentication, plus fast symmetric encryption—is central to how this works in practice.

What is actually shipping as of November 5, 2026?

An announced feature, an available adapter, and a supported end-to-end configuration are different things. Dell’s software matrix updated November 2 lists PowerStoreOS 5.1.0.0, build 2798105, released October 29, 2026 as the newest release for PowerStore T and Q models, while Dell’s PowerStoreOS matrix (KB 000175213) identifies 4.3.1.2 LTS2026, build 2771239 as the currently recommended 2026 LTS release. Latest and recommended are not equivalent operational designations.

Component	Published status	Verify before production
Emulex SecureHBA	LPe37100 (32G) / LPe38100 (64G) families shipping	Server card, supported driver/firmware, compatible array peer
Everpure FlashArray	First storage vendor in Broadcom’s March announcement	Exact supported controllers, adapters, software
Dell PowerStore	PowerStoreOS 5.1.0.0 released October 29	Gen 3, supported FC card and PowerEdge/SecureHBA pairing
Brocade FOS 10.x	PQC-capable SSH/TLS, LMS-signed firmware	Supported switch and actual management protocol negotiation
Brocade Extension	PQC IPsec profile available in FOS 10.0.x	Certificate trust, peer and active negotiated profile

1. Server to array: Emulex SecureHBA encrypts the actual Fibre Channel traffic

On March 19, 2026, Broadcom announced a shipping end-to-end in-flight encryption solution pairing Emulex SecureHBAs on servers with compatible HBAs in storage arrays. Everpure FlashArray was identified as the first storage platform to embed the adapters. Broadcom reported that more than 120,000 SecureHBAs had shipped on OEM server platforms over the preceding year; that is a dated March figure, not a claim about the current installed base.

The mechanics are compelling to an architect because encryption is performed in hardware at the Fibre Channel endpoints:

• Data protection: AES-256-GCM encrypts the Fibre Channel data in flight.
• Quantum-resistant key establishment: ML-KEM-1024 is used in establishing the session; ML-DSA-87 supports cryptographic authentication, consistent with the CNSA 2.0 algorithm direction.
• Session lifecycle: compatible endpoints authenticate and establish independently keyed, short-lived sessions during Fibre Channel login, with automatic rekeying.
• Operations: in-flight session establishment does not require an external key-management service or host-side application changes. Encryption work is offloaded to the HBA rather than consuming server/array CPU for data-path cryptography.
• Storage services: the array can decrypt data at its FC adapter before deduplication, compression, and other storage services, avoiding a common penalty of encrypting application data before it reaches the storage platform.

The crucial qualification: both endpoints must support the feature. A SecureHBA in a server does not magically create end-to-end encryption if the array port, driver, firmware, or platform combination does not support the negotiated secure connection. Review your supported hardware matrix and confirm that encryption is actually negotiated; do not use the adapter’s part number as proof of protection. Broadcom also identifies the hardware-offload design and key-management process in its technical brief.

The operational trap: a healthy FC link can be unencrypted

A critical detail in Dell’s 2025 Tolly evaluation (report #225142) is easy to miss: when a SecureHBA connects to an array without autonomous encryption capability, the Fibre Channel connection can still establish without encryption. Healthy multipathing, a successful port login, and working I/O do not prove that a PQC-negotiated encrypted session is active.

Operational response: inventory negotiated encrypted connections, record exceptions, and test how each supported endpoint behaves when secure negotiation is unavailable. Broadcom’s SecureHBA product brief describes SAN Manager’s per-port encryption views. If policy forbids plaintext, verify the specific supported configuration’s enforcement controls rather than assuming “automatic encryption” means fail-closed.

SecureHBA encryption does not depend on a FOS 10 switch

Dell’s test report specifically notes that endpoint encryption does not require a switch-level encryption feature: its testbed used a Dell Connectrix B-Series DS7720B on FOS 9.1.1. This does not remove switch patching or upgrade obligations. It proves that HBA-to-array encrypted I/O is a different control from FOS 10.x PQC SSH/TLS management.

What was measured in the Dell/Tolly lab

Dell commissioned validation using a PowerEdge R770 with an Emulex LPe38102 64G SecureHBA. The published FIO result reached more than 92.4% of the calculated 64GFC maximum with encryption active, and HammerDB Oracle workload runs at 256 users were nearly identical with encryption on and off. These are encouraging benchmark results, not universal no-overhead guarantees. The report identifies firmware 14.14.436.7 and LPFC driver 14.4.393.31 as its test versions, not a blanket deployment prescription.

The study also validated SPDM device attestation with iDRAC 10, blocking of an unauthenticated firmware load, and a tested SPDM 1.2.0-capable configuration. Secure boot, silicon root of trust, device attestation, and encrypted FC payloads are distinct mechanisms requiring distinct validation.

Dell expands the story beyond the first array

This is no longer solely a March 2026 milestone. In May 2026, Broadcom described the Dell PowerStore Elite and PowerEdge SecureHBA implementation as another stage in end-to-end PQC-ready protection. Dell’s October 27 announcement subsequently described PQC-ready Fibre Channel encryption for supported PowerStore Gen 3 configurations, referring to the latest PowerStore software without identifying a release number. The exact version and availability come from Dell’s PowerStoreOS matrix (KB 000175213): PowerStoreOS 5.1.0.0, build 2798105, released October 29. Supported PowerEdge servers, SecureHBAs, storage platforms and their interoperable software combinations must be verified in the applicable support documentation, rather than inferred from an individual announcement. The offload approach lets the array retain data-reduction and other storage functions.

That is the kind of cross-vendor, standards-led integration the market needs: not just an HBA with a promising capability, but a practical way to secure a real server-to-array path. Dell’s PowerEdge/SecureHBA test report offers further implementation context.

2. Inside the fabric: FOS 10.x hardens the infrastructure that carries the traffic

The storage network is more than its data payload. Administrators log into switches, management tools establish TLS sessions, firmware must be trusted, and switches establish relationships with peers. A quantum-safe strategy needs to examine all of those trust boundaries.

Brocade Fabric OS v10.0.1 release notes document PQC algorithm support including ML-KEM (512/768/1024), ML-DSA (44/65/87), and LMS for FOS firmware signatures. The listed use cases include SSH key exchange and host keys, TLS signing/verification, and TLS key encapsulation. The release covers Gen 7 and Gen 8 hardware platforms, subject to model-specific support and upgrade prerequisites. Gen 6 platforms, including G610, G620, G630 and X6, are not FOS 10.x upgrade targets; they remain on the supported 9.2.x software family. Inventory the switch generation before planning a management-plane PQC rollout. Broadcom’s quantum-safe storage-fabric overview places these mechanisms alongside fabric monitoring, hardening, and hardware trust.

An essential distinction: PQC-capable SSH/TLS management and signed firmware are not the same thing as encrypted host-to-array data traffic. Nor does an operating-system upgrade prove that every inter-switch link is using a particular post-quantum authentication and encryption profile. Review the specific FOS security and ISL configuration for your supported topology, including certificate/trust dependencies, peer compatibility, policies, downgrade constraints, and what your monitoring systems can actually attest.

FOS 10.0.1: exactly what the release notes document

Section 4.2.2.5 of the June 25, 2026 FOS 10.0.1 release notes makes the distinction concrete. Available algorithm families include ML-KEM-512/768/1024, ML-DSA-44/65/87, and LMS for firmware signatures. Documented roles include ML-DSA SSH keys, ML-KEM and hybrid OpenSSH key exchange, ML-DSA TLS signing and verification, and ML-KEM-based TLS encapsulation. Available is not the same as negotiated or enabled. The default seccryptocfg profile does not automatically select post-quantum SSH key exchange or TLS encapsulation just because FOS 10.x is installed. Administrators must select and apply supported cryptographic options, validate client and peer compatibility, and verify the algorithms actually negotiated. LMS-signed firmware is a distinct security mechanism; it should not be confused with enabling PQC for management sessions.

• SSH interoperability: the release notes describe testing against OpenSSH_10.2-2025-12_p1 and Open Quantum Safe 2025-12. Older SSH/SCP automation clients may have algorithm negotiation issues.
• Unsupported combinations: FrodoKEM variants can appear configurable but are specifically not supported by FOS 10.0.1.
• Check configuration first: the release notes describe seccryptocfg --show, --export, --import and --apply for reviewing, transferring and applying cryptographic profiles in a specific SSH/SCP interoperability scenario. Verify the running configuration and change-control requirements before modifying production settings.
• Upgrade planning: confirm Gen 7/Gen 8 model support, SANnav compatibility, supported paths, maintenance behavior and downgrade caveats. FOS 10.x restricts weak SNMPv3 settings, and upgrade procedures can remove previously installed user scripts.

FOS 10.0.1 also adds 128G long-wavelength and extended-long-wavelength optics support plus SAN Fabric Intelligence scaling and monitoring updates. Those are valuable platform changes, but neither high-speed optics nor visibility alone establishes quantum-resistant encrypted I/O.

A separate current security reason to check switch firmware

On October 6, 2026, Broadcom disclosed several Fabric OS vulnerabilities affecting releases before FOS 10.0.1, identifying 10.0.1 as the release containing fixes: CVE-2026-87682 (management command injection), CVE-2026-87684 (SNMP daemon handling), CVE-2026-87659 (in-band management authorization bypass), and CVE-2026-87665 (IKEv2/Extension processing). This is conventional vulnerability management alongside, not equivalent to, PQC adoption. Not every older platform can upgrade directly to every new major release; determine the supported remediation path for each OEM-specific switch.

3. Between sites: post-quantum IPsec for Fibre Channel Extension

A storage fabric can be tightly isolated inside a data center yet still need to carry replication traffic over a provider network. That introduces a different interception surface. Brocade’s Extension Design and Best Practices guide documents an IPsec PQC profile introduced with FOS 10.0.0. When selected, IKEv2 supports ML-KEM-768 for key establishment and ML-DSA-65 for certificate-based authentication.

The algorithm sizes differ from the SecureHBA’s ML-KEM-1024/ML-DSA-87 combination because these are distinct implementations protecting distinct boundaries. Do not treat the presence of a capable Extension switch as evidence that a legacy PSK/PKI tunnel has been upgraded: the PQC profile has to be selected and its certificate trust configured. Confirm the negotiated profile, both endpoints, performance, and failover behavior in a representative replication test.

Extension: certificate requirements and operational evidence

The Brocade Extension Design and Best Practices guide, section 3.12 distinguishes existing PSK and PKI profiles from the selectable PQC IPsec profile. It documents SecCertMgmt generation of ML-DSA-65 certificate requests/self-signed certificates; a remote self-signed peer certificate must be imported, while CA-signed peers require trust in the issuing CA certificate. For the supported hardware implementation the guide cites line-rate processing and approximately 5 microseconds added propagation delay. Verify the actual data path and latency in your environment rather than using those figures as universal SLAs.

The FOS 10.0.1 notes add responder-side IKE ESP rekey statistics via portshow ipsec-policy --ike [-detail], and specifically say these additional responder statistics are CLI-only in that release. That is exactly the kind of evidence an operator can add to a runbook, alongside actual policy selection, trust verification, tunnel status, failover behavior and replication health.

Why FC-SP-3 matters: this is a standard, not just a vendor feature

The Fibre Channel Industry Association announced completion of FC-SP-3 in February 2026; the standard was published as INCITS 577-2026. FC-SP-3 establishes updated security mechanisms and interoperability profiles, including ML-KEM-1024 and ML-DSA-87, while retiring obsolete cryptographic options from earlier generations. StorageReview’s September analysis explains the migration value particularly well.

Standards give hardware and storage vendors a common language; they do not automatically deploy encryption. Procurement teams should ask for the supported FC-SP-3 interoperability profile, verified firmware versions, negotiated security status, and operational evidence, not settle for the word “quantum-safe” in a product description.

Where this fits in VMware Cloud Foundation—and where vSAN is different

Many VMware Cloud Foundation environments use external Fibre Channel storage alongside their other storage choices. For those environments, quantum-safe FC transport can be part of the storage security discussion without changing how the virtual machines consume datastores. Marcus Thordal’s VMware Explore presentation, “The Path to a Quantum Secure VMware Cloud Foundation Storage Infrastructure,” is a useful related session for this broader architectural conversation. See also my earlier Definitive Guide to VCF Storage for the storage-options backdrop.

vSAN deserves a careful distinction. vSAN’s October 6, 2026 FAQ (page 42) describes the typical deployment using standard NICs and Ethernet-based traffic, not a Fibre Channel HBA for its existing storage data path. Its wording also notes that vSAN is evolving to take advantage of existing hardware investments. Meanwhile, Broadcom’s March SecureHBA release explicitly referred to announced plans for native Fibre Channel support in VMware vSAN Storage Clusters and Microsoft Azure Local. Those forward-looking statements should not be confused with a currently supported, generally available vSAN Fibre Channel deployment. Verify product documentation, release scope, and interoperability before designing around a future capability.

The April 2026 vSAN datasheet emphasizes that the conventional vSAN architecture avoids specialized Fibre Channel networking. The takeaway is not “Fibre Channel versus vSAN”; it is match security controls to the actual storage transport you run today and distinguish announced roadmaps from supported production designs.

Using Fibre Channel as the vSAN transport: investment protection, not external array consumption

There is an important piece of publicly discussed roadmap context behind that distinction. In Duncan Epping’s January 2026 discussion of vSAN over Fibre Channel with Rakesh Radhakrishnan, the proposed capability is described as using Fibre Channel as a transport for vSAN communications instead of Ethernet. It is not a proposal for vSAN to consume external Fibre Channel arrays as its local storage devices. VCF already supports traditional external FC storage as an independent option, as the November 4, 2026 VCF FAQ makes clear.

That is significant for existing FC investments: organizations with an established SAN fabric could eventually have another way to deploy vSAN Storage Clusters without assuming that all storage transport must move to Ethernet. The October 25, 2026 Unexplored Territory discussion with vSAN platform product management revisits the idea as part of a broader vSAN roadmap. For additional public roadmap context, VMware Explore 2026 also featured vSAN over Fibre Channel: Modernizing Storage without Abandoning Your Fabric, focused on preserving SAN investment while evaluating a future Fibre Channel transport for vSAN. The accompanying roadmap disclaimer is essential: no specific release date, HBA compatibility list, or implementation details should be treated as a committed, supported design. In particular, the presence of an Emulex SecureHBA does not by itself establish that its PQC-based in-flight encryption is supported for a future vSAN-over-FC deployment.

For organizations beginning inventory and design assessments, the publicly available VCF Readiness Assessment Tool can identify installed Fibre Channel HBAs and other hardware characteristics. Its assessment output and family-level classifications are planning aids, not a future vSAN Fibre Channel hardware compatibility list. I previously explored the broader use of the tool in De-Risking Day 0 with the Open-Source VCF Readiness Tool. Product release notes and official support matrices—not pre-release expectations or heuristic badges—must ultimately govern production architecture.

VCF architects: external FC and vSAN do not use the same encryption path

VMware’s vSAN FAQ dated October 6, 2026 is worth reading beyond its HBA question. It explains that a typical vSAN deployment uses standard NICs, with vSAN traffic over TCP/Ethernet or configured RDMA over converged Ethernet. Separately, it says vSAN ESA can encrypt data high in the storage stack for both in-flight and at-rest protection, and describes VCF 9.1 support for data-in-transit encryption between remote vSAN datastores and consuming clusters. Those built-in vSAN protections are distinct from the Emulex/Brocade Fibre Channel mechanism and should not be described as PQC without separate documentation.

The March Broadcom announcement spoke of plans for native Fibre Channel support in vSAN Storage Clusters and Azure Local, while the latest vSAN FAQ still describes conventional NIC-based deployment. Treat those plans as a roadmap, not a generally available production support statement. Map FC-backed external storage, vSAN networking, storage replication and management traffic separately before choosing controls.

An architect’s verification checklist: what I would ask before calling it quantum-safe

• Map the path: identify which data moves over FC, which moves over Ethernet, and which crosses the WAN. Include backup, replication, and recovery flows.
• Check the endpoints: confirm matching SecureHBA and storage-array capabilities, OS/driver/firmware support, and the exact negotiated encrypted-session state.
• Audit the fabric: inventory switch generations and FOS releases; review SSH/TLS algorithm negotiation, switch authentication, firmware trust, and ISL encryption as separate controls.
• Prove Extension configuration: verify that the PQC IPsec profile is actually in use, certificates validate, and failover does not fall back to an unintended weaker configuration.
• Measure operations: gather audit-friendly evidence of encrypted ports and sessions—using platform reporting and tools such as Emulex SAN Manager 3.0 where supported—and test throughput, latency, and recovery.
• Keep compliance claims precise: CNSA 2.0 alignment and controls relevant to NIS2 or DORA can help a program, but no adapter or switch automatically makes an entire organization compliant.

A concise audit-evidence pack for storage and security teams

• Encrypted data path: initiator/array identifiers, supported adapter combinations, negotiated encryption state and plaintext exceptions.
• Fabric control plane: FOS inventory, switch-management SSH/TLS algorithms, certificate trust, signed firmware verification and applicable advisories.
• WAN Extension: negotiated PQC IPsec policy, peer certificates, IKE/rekey evidence, failover behavior and replication health.
• Performance: application-level workload latency, IOPS and throughput in a representative tested configuration.
• Lifecycle: re-check after HBA or array replacement, firmware upgrade, site failover, and any change that might lead to plaintext fallback.

The bottom line: the cable matters now

The question is no longer simply whether quantum computing will eventually threaten enterprise data. It is whether we can demonstrate how long-lived data is protected on every relevant transport path today.

For someone who spent years immersed in Brocade architecture—and who earned the BDA credential back in 2014—seeing the fabric evolve to address post-quantum security is especially rewarding. For the people responsible for protecting actual production workloads, the opportunity is more practical: use standards, supported hardware, and verifiable configuration to close gaps in data-in-flight protection before today’s captured traffic becomes tomorrow’s problem.

This article reflects public vendor documentation and standards information available as of November 5, 2026. Validate compatibility and release status against current support matrices before production changes.

Primary sources and further reading

• Broadcom: Emulex SecureHBA end-to-end PQC-safe encryption announcement (March 19, 2026)
• Broadcom: Emulex SecureHBA autonomous encryption technical brief
• Brocade Fabric OS v10.0.1 release notes
• Brocade Extension Design and Best Practices — PQC IPsec profile
• Brocade: AI Threat-Secure, Quantum-Safe Storage Fabric
• FCIA: completion of FC-SP-3 · StorageReview analysis
• Dell: PowerStoreOS 5.1 PQC readiness announcement (October 27, 2026)
• VMware: vSAN FAQs (October 6, 2026) · vSAN datasheet
• VMware Explore: The Path to a Quantum Secure VCF Storage Infrastructure
• NIST FIPS 203 — ML-KEM · NIST FIPS 204 — ML-DSA

Further implementation references and recent security documents

• Broadcom SecureHBA LPe37100/LPe38100 product brief — supported features, speeds and management security visibility.
• Dell / Tolly SecureHBA study (2025; report #225142) — endpoint compatibility, SPDM test, 64G FIO performance and Oracle HammerDB.
• Dell latest/recommended code matrix (updated November 2) — PowerStoreOS 5.1.0.0 availability and LTS distinction.
• Dell PowerStore documentation and release notes — PowerStoreOS 5.1 release documentation.
• Brocade FOS management advisory · SNMP advisory · in-band management advisory · IKEv2 advisory (October 6, 2026).