Blog

Hybrid Cloud Survival Guide, Part 4: Decrypting and Demystifying CSfC and PQC for Federal Agencies

May 5, 2026 By Joe Bailey

For federal customers, security claims only matter when they hold up under scrutiny. That is especially true when the conversation moves into classified environments, long-retention data, and quantum-era cryptography. In those environments, storage is not just infrastructure, it becomes part of the trust boundary.

Two main areas are going to be top of mind for federal agencies for the foreseeable future when it comes to securing the hybrid cloud. Commercial Solutions for Classified (CSfC) and post-quantum cryptography (PQC) readiness.

These are complex topics and the goal is not to treat those as badges. The goal is to understand what they mean, where they matter, and how they should influence the storage decision for agencies, integrators, and mission owners who need a platform that can hold up against both current requirements and longer-term cryptographic risk.

That is why digging into NetApp’s role in helping federal agencies understand the future of security when it comes to hybrid clouds matter because NetApp’s federal position encompasses both CSfC and PQC in addition to their traditional standard encryption or ransomware protection capabilities.

Classified Storage is Not a Generic Requirement

When a federal customer is dealing with classified data, “secure storage” is too broad to be useful. The real question is whether the platform aligns to the controls and component paths the government already recognizes for classified protection. That is where CSfC becomes relevant.

NetApp’s Trust Center states that ONTAP is listed on the NSA’s CSfC Program Components List Index and points directly to the hardware and software full drive encryption entries. On the NSA components list itself, NetApp appears under Hardware Full Drive Encryption as NetApp Storage Encryption (NSE) and under Software Full Drive Encryption as NetApp Volume Encryption (NVE) ONTAP 9.14.1.

That is a practical takeaway. This is not just a generic security claim. It is a position tied to a visible federal validation path. If your environment includes classified handling requirements, that should move the conversation from general product comparison to a more serious discussion about fit, scope, and architecture.

Does Your Storage Require CSfC Encryption

NetApp’s current messaging says the company is the only enterprise storage vendor validated by the NSA’s CSfC Program, and its Trust Center and supporting collateral continue to point buyers to that position. The useful question for a federal customer is not whether that sounds impressive. The useful question is whether your mission requires storage that aligns to NSA CSfC-listed encryption components.

If the answer is yes, NetApp belongs in the conversation early. That does not settle the architecture by itself, but it does change the shortlist. It means the platform is relevant not just because of general security features, but because it maps to a requirement space many commercial storage discussions never reach.

If the answer is no, the CSfC angle may still matter as a trust signal, but it should stay in proportion to the mission need. Federal buyers still need to evaluate operating model, supportability, cloud alignment, and how the storage layer fits the larger environment.

Honestly Evaluate Post-Quantum Readiness

Post-quantum cryptography is another area where vague language causes problems. Federal customers should stay practical here. The question is not whether a vendor says “quantum-safe.” The question is what the platform is doing today for data in transit and data at rest, and how that lines up with NIST guidance and longer-term risk.

NetApp’s current PQC messaging centers on securing the storage layer for both data at rest and data in flight. NetApp’s April 2025 product update says its post-quantum cryptography for at-rest data is compliant with NIST PQC algorithms, and NetApp’s PQC page positions the company around NIST-aligned PQC and storage-layer readiness more broadly.

The nuance matters on the in-transit side. ONTAP documentation shows that beginning with ONTAP 9.18.1, SSL supports the ML-KEM, ML-DSA, and SLH-DSA post-quantum cryptographic algorithms, but those algorithms are available when FIPS mode is disabled and the peer supports them. ONTAP documentation also states that when SSL FIPS mode is enabled, ONTAP uses FIPS-compliant crypto for SSL connections.

That is the detail federal buyers need to understand. If your environment is balancing strict FIPS operation with emerging PQC SSL algorithms, you need to work through the current behavior carefully instead of assuming every requirement is satisfied by default.

The Different Conversations Around Data at Rest and Data in Transit

For data at rest, NetApp’s story is steadier. ONTAP supports software and hardware encryption options such as NVE, NAE, and NSE, and NetApp has long used AES-256 as a core at-rest encryption approach.

That matters because NIST and ETSI continue to treat strong symmetric cryptography differently from legacy public-key schemes in the quantum discussion. NIST’s PQC FAQ states that AES-192 and AES-256 are expected to remain safe for a very long time, and ETSI’s quantum-safe cryptography report similarly concludes that existing symmetric primitives such as AES-256 should withstand quantum computer attacks until way after 2050 under the report’s assumptions.

The practical takeaway is simple. Federal customers should not collapse at-rest and in-transit cryptography into one conversation. NetApp’s at-rest story is built on mature symmetric encryption. Its in-transit PQC story is evolving with ONTAP releases and needs to be evaluated against your FIPS posture and interoperability requirements.

This is Not an Asset Discovery Story

It is also worth being clear about what NetApp is and is not doing here. NetApp provides PQC-related cryptographic capabilities at the storage layer. It does not provide a discovery tool that scans your broader IT estate to identify which storage, servers, endpoints, or network devices are not using PQC.

That distinction matters because federal customers often need both conversations. One is about whether the storage platform itself supports the right cryptographic path. The other is about broader infrastructure inventory and transition planning across the environment. NetApp contributes to the first problem. It does not claim to solve the second one by itself.

That is the healthier way to view it. Storage-layer PQC matters, but it should be evaluated as one part of a broader cryptographic transition strategy.

Questions to Consider

For federal buyers, the most useful questions are straightforward:

  • Do you have mission or program requirements that make CSfC alignment relevant?
  • Do you need a storage platform with NSA-listed encryption components on the CSfC Components List?
  • Do you need a credible at-rest encryption story that remains strong in a post-quantum discussion?
  • Do you need to begin planning for post-quantum data-in-transit protections at the storage layer?
  • Do you understand how your FIPS requirements interact with ONTAP’s current PQC SSL support?

Those are the questions that move this from marketing into architecture. If the answer to several of them is yes, NetApp’s CSfC and PQC position should carry real weight in the decision. If not, these may still be useful differentiators, but they should stay tied to the actual mission need.

A Final Thought in this Series

Across this series, the same pattern has come up again and again. Federal customers are not just choosing a storage platform. They are choosing an operating model. In the first post, that meant deciding whether FSx for ONTAP or Cloud Volumes ONTAP was the better fit for the mission, the team, and the support model. In the second, it meant looking at BlueXP as a way to reduce management fatigue across a distributed estate. In the third, it meant treating storage security as part of cyber resilience instead of an afterthought. This final post brings that conversation to its endpoint: trust, compliance, and long-term cryptographic readiness at the storage layer.

That is the mission benefit. The right storage platform should not just meet a feature checklist. It should reduce operational drag, improve recovery confidence, support compliance, and give federal teams confidence that the storage layer will hold up under both current and future security demands. When the storage layer is chosen well, it quietly strengthens the mission. When it is chosen poorly, it becomes another source of friction, risk, and administrative overhead.

Swish Turns Capabilities into Mission-Aligned Decisions

This is one of those topics where federal customers need interpretation more than a feature dump. The important thing is not just knowing that NetApp has CSfC-related listings or PQC messaging. The important thing is understanding how those details map to your environment, your handling requirements, your FIPS posture, your hybrid cloud operating model, and your longer-term cryptographic transition plan.

At Swish, this is where we help customers turn platform capabilities into mission-aligned design decisions. We work with agencies, primes, and integrators to evaluate the full picture: the right ONTAP operating model in AWS, how to reduce management fatigue across regional and global footprints, how built-in security features support resilience, and how CSfC and PQC considerations should shape the storage decision for federal environments. That gives teams a stronger basis for selecting a platform they can defend technically, operate consistently, and trust over time.

If your organization is planning a hybrid cloud modernization effort, a classified storage architecture, or a broader cyber resilience update, this is the right time to step back and evaluate whether the storage layer is truly aligned to the mission. If you need help turning NetApp’s cloud, security, CSfC, and PQC capabilities into a decision framework that holds up operationally and supports the mission, Swish can help.