BitLocker and other commercial encryption products provide strong protection for everyday enterprise data. But classified information faces a fundamentally different threat, and requires a fundamentally different security architecture. Most modern computers can encrypt their storage. Microsoft Windows includes BitLocker. Commercial security vendors such as Trellix offer full-disk encryption technologies. Many enterprise SSDs even include built-in encryption. So why isn’t that enough for classified information? The answer comes down to who you are protecting the data from, and what happens if they physically obtain the device.
Commercial encryption is generally designed to address risks such as:
Classified systems must account for something considerably more serious, a sophisticated adversary with:
That adversary may be a nation-state intelligence service. For this threat environment, the National Security Agency (NSA) established the Commercial Solutions for Classified (CSfC) program and its Data-at-Rest (DAR) Capability Package. Rather than relying on a single encryption product, CSfC uses evaluated commercial technologies within a prescribed security architecture incorporating:
That distinction, an encryption feature versus a security architecture, is fundamental to understanding why CSfC matters.
A CSfC Data-at-Rest (DAR) architecture is an NSA-defined approach for protecting classified information stored on devices using appropriately evaluated commercial components configured in approved, layered solution designs. The current NSA CSfC Data-at-Rest Capability Package Version 5.1.0, dated March 2026, defines the solution designs and implementation guidance for these protections. CSfC focuses on the complete protection architecture, including independent encryption layers, authentication, component selection, and configuration, rather than relying on a single encryption product.
Products such as Microsoft BitLocker provide valuable protection and are widely deployed for good reason. BitLocker, for example, encrypts Windows volumes and can use a Trusted Platform Module (TPM) as part of protecting cryptographic key material and validating aspects of the system’s boot environment. Properly configured, it provides strong protection against many common scenarios involving lost or stolen computers. But “encrypted” does not automatically mean “approved to protect classified information.”
For classified information, the questions go considerably deeper:
CSfC addresses these questions at the solution architecture level, rather than simply asking whether encryption is enabled.
The easiest way to understand CSfC DAR is to think about the difference between one security barrier and multiple independent barriers. A conventional full-disk encryption implementation can provide a strong cryptographic boundary. But if an attacker discovers a way around that boundary, through its authentication mechanism, implementation, configuration, key handling, boot process, or another trusted component, the protected information may become accessible.
NSA’s CSfC approach emphasizes defense in depth. CSfC DAR architectures use independently protected encryption layers implemented with components selected and configured according to NSA’s Capability Package.
The principle is straightforward: Compromise of one security layer should not automatically compromise the classified information. An attacker who defeats one layer should still encounter another independently implemented cryptographic barrier.
Importantly, this isn’t simply “encrypting something twice.” Independence matters. If two encryption layers share the same vulnerability, key-management weakness, code base, or other common point of failure, the value of the second layer can be substantially reduced. CSfC therefore considers the independence of the components used to construct those security layers. That’s fundamentally different from simply turning on an encryption feature.
An important technology used within DAR architectures is hardware full-drive encryption (HWFDE). With software full-drive encryption, the computer’s processor performs encryption and decryption. The encryption software therefore operates within, and necessarily depends upon portions of, the host computer’s hardware and software environment.
A self-encrypting drive, or SED, approaches the problem differently. The cryptographic engine resides within the storage device itself. Data written to the storage media is encrypted by the drive, and decryption occurs within the drive when properly authorized.
This creates an important security boundary between the storage device and the host computer. Until properly unlocked, the SSD can keep the underlying information cryptographically inaccessible regardless of whether the operating system wants to read it. This moves a critical part of data protection below the operating system and into dedicated storage hardware and firmware.
For an attacker, that’s significant.
However, there’s an important caveat: Hardware encryption is not automatically secure simply because encryption occurs inside an SSD. A commercial self-encrypting drive is not necessarily appropriate for classified information. The implementation of the encryption engine, authentication mechanism, firmware, cryptographic functions, and key-management processes all matter. That’s precisely why independent evaluation and CSfC component requirements are important.
This is one of the most important, and frequently misunderstood, concepts in protecting classified data at rest. A self-encrypting drive can provide an extremely strong hardware encryption boundary. But an encrypted drive is only as secure as the mechanism controlling when and why it unlocks. Think about a high-security safe. The walls could be constructed from extraordinarily strong steel. The safe could resist drilling, cutting, and physical attack. But imagine that the safe has no meaningful lock. Or imagine that the safe automatically unlocks whenever someone turns on the lights in the room. The strength of the steel becomes largely irrelevant. The encryption engine is the safe. Authentication is the lock. A SED without meaningful pre-boot authorization can create a similar security problem. The encryption engine inside the drive may use exceptionally strong cryptography. But if the computer automatically supplies everything necessary to unlock that drive during startup, an attacker may not need to defeat the encryption algorithm at all. Instead, the attacker can focus on the process that causes the safe to open.
That distinction is critical.
Encryption protects the data. Authentication controls access to the mechanism that releases the data. Both are necessary. Why the Windows Login Isn’t the Same Thing Users naturally think of the Windows login screen as the point where access to their computer begins. Technically, however, a great deal has already happened by the time that screen appears. The computer has powered on. Firmware has executed. Hardware has initialized. Boot components have run. Portions of the operating environment may already be active. If the encrypted storage has already been unlocked during that process, the security architecture may be relying on the host environment to protect information that the storage device has already made available.
Pre-Boot Authentication (PBA) changes that sequence. With an appropriately implemented PBA architecture, authorization is required before the protected storage is made available for normal operating-system use. The user must successfully satisfy the authentication requirement before authorization is provided to unlock the encrypted drive. Think of the difference this way: SED without meaningful PBA The classified information is inside a very strong safe, but the safe automatically opens when the computer starts. SED with PBA The classified information is inside a very strong safe, and an authorized user must independently prove they are permitted to open it before the door unlocks.
For classified systems, that difference is enormous. An adversary may possess the entire computer: motherboard, TPM, firmware, SSD, boot environment, operating system, everything. If the drive automatically unlocks during a normal boot sequence, the attacker can concentrate resources on reproducing, intercepting, manipulating, or bypassing that process. With independent pre-boot authentication, physical possession of the computer is not sufficient to unlock the storage. The adversary must also overcome the authorization mechanism protecting it. This helps explain why CSfC architectures distinguish between the Encryption Engine (EE) and Authorization Acquisition (AA) functions. The Encryption Engine provides cryptographic protection. Authorization Acquisition controls the authorization necessary for that protection to be removed for a legitimate user. A strong encryption engine paired with weak authorization can still result in a weak system. The vault and the lock both matter.
Another common misconception is that two products using the same encryption algorithm provide the same level of security. They don’t. A commercial encryption product and a CSfC DAR solution may both ultimately employ AES-256. But saying that makes them equivalent is like saying two buildings are equally secure because both have doors made from the same steel. One building might have a single lock. The other might have multiple independently controlled barriers, identity verification, alarms, access procedures, and a vault. The material may be equally strong. The security architecture is not. The same principle applies to encryption. For sophisticated attackers, the cryptographic algorithm itself may be one of the strongest parts of the system. The more attractive targets can be the systems surrounding it.
Modern cryptographic algorithms such as AES-256 are extraordinarily strong when implemented correctly and when their keys remain secret. A nation-state adversary is therefore unlikely to begin by attempting to mathematically brute-force AES-256. They don’t have to. Instead, the objective is often to find another way to obtain the plaintext or the information necessary to unlock it. Potential areas of attack can include: authentication mechanisms; cryptographic key handling; firmware; boot components; operating-system vulnerabilities; configuration errors; credential capture; memory containing sensitive information; hardware interfaces; implementation flaws; and weaknesses elsewhere in the chain of trust. The attacker’s objective isn’t necessarily: “How do we break AES?” It’s: “What is the easiest path around AES?” This distinction is fundamental to high-assurance security.
Encryption is ultimately dependent on keys. A perfectly implemented encryption algorithm provides little protection if an attacker obtains the key, or can cause the system to release it. This makes key creation, protection, storage, and authorization just as important as the encryption algorithm itself. Commercial full-disk encryption products can employ sophisticated key hierarchies and hardware such as TPMs to protect key material. Those designs can provide excellent protection for their intended use. The classified-data threat model goes further. Security architects must consider questions such as: How is key material generated? Where does it exist? What protects it while stored? What authorization causes it to become usable? Can physical possession of the computer provide access to the mechanism protecting it? What happens if one component responsible for protecting or releasing the key is compromised? Does another independent encryption boundary remain? This leads to a much better question than simply asking whether a laptop is encrypted. Instead ask: What would a sophisticated adversary have to defeat before classified plaintext becomes available? That’s the question a high-assurance DAR architecture is designed to answer.
Imagine that a laptop containing classified information disappears during an overseas operation. Now assume it doesn’t end up with an ordinary thief. Instead, it is delivered to a sophisticated foreign intelligence service. The adversary may have: unlimited physical access to the device; specialized electronics and forensic laboratories; experts in operating systems, firmware, cryptography, and semiconductor analysis; the ability to disassemble and instrument hardware; extensive knowledge of published vulnerabilities; significant capability to discover previously unknown vulnerabilities; the ability to purchase identical computers and drives for testing; custom hardware and software designed specifically for the attack; and days, weeks, or months to work on the target. That’s a dramatically different threat environment from ordinary laptop theft. Physical possession also enables categories of attack that remote security controls were never intended to address. A sophisticated adversary can potentially investigate boot manipulation, firmware compromise, credential interception, hardware interfaces, memory-based attacks, key-recovery opportunities, or implementation weaknesses surrounding the cryptography. Once again, the attacker doesn’t necessarily need to defeat the strongest cryptographic component. They only need to find the weakest path to the key or plaintext.
One of the most powerful principles behind CSfC is also one of the simplest: No commercial product should be assumed to be perfect. Software can contain vulnerabilities. Firmware can contain vulnerabilities. Hardware can contain vulnerabilities. Security products can contain vulnerabilities. And even excellent products can be incorrectly configured. CSfC addresses this reality architecturally. Instead of asking one commercial product to provide every protection necessary for classified information, the architecture combines appropriately evaluated and configured commercial components into independent layers. If one layer contains a vulnerability or is compromised, the intent is for another independent layer to continue protecting the classified information. That’s why defense in depth is so important. And it’s why two independent layers are fundamentally different from simply having two security products installed on the same computer.
Another major difference between ordinary commercial encryption and CSfC is evaluation. Products intended for use as CSfC components must satisfy applicable requirements and undergo required evaluation and validation processes before they can be used in the relevant role within a CSfC solution. But being on a list isn’t enough. The Capability Package describes how components must be selected, combined, configured, provisioned, operated, and maintained. That’s an important distinction for acquisition officials and program managers: CSfC isn’t simply about buying an approved product. It’s about implementing an approved architecture. A product configured differently from the way it was evaluated can alter the security assumptions behind that evaluation. The security comes from the complete system: architecture + evaluated components + correct configuration + operational procedures.
| Commercial Enterprise Encryption | CSfC Data-at-Rest Architecture |
| Primarily designed around commercial and enterprise threat models | Designed to protect classified National Security Systems data |
| Often relies on one primary encryption boundary | Uses layered protection architectures |
| Product-focused | Architecture-focused |
| Can use very strong cryptography such as AES-256 | Combines approved cryptography with defined architectural requirements |
| May depend heavily on the host OS and TPM | Can establish independent protection boundaries across software, authentication, and storage hardware |
| Architecture is primarily determined by the vendor/customer | Solution requirements are defined by NSA Capability Packages |
| Testing and certification vary | Components must meet applicable evaluation and validation requirements |
| Key protection depends on the product and configuration | Key handling and authorization are considered within the overall architecture |
| Often optimized for lost/stolen devices and enterprise attackers | Designed with sophisticated threats to classified information in mind |
| Failure of the primary encryption boundary can potentially expose DAR | Independent layers reduce reliance on any single security boundary |
CSfC shouldn’t be described as making a computer invulnerable. DAR architectures address a specific problem: protecting classified information at rest, including when the device is powered off or remains unauthenticated. Once an authorized user has authenticated and applications legitimately require access to classified information, the system eventually must make that information available for processing. At that point, other protections remain essential: endpoint security, malware defenses, access controls, configuration management, physical security, monitoring, and operational procedures. CSfC DAR therefore isn’t a replacement for cybersecurity. It solves one particularly important part of the problem: If an unauthorized party physically obtains this device while its data is protected, what stands between that adversary and the classified information stored on it? For classified systems, the answer should be considerably more than: “We turned on disk encryption.”
Today’s national-security mission is increasingly mobile and distributed. Military personnel, engineers, analysts, program managers, contractors, and other authorized users cannot always perform their work from inside permanently secured facilities. That creates an unavoidable challenge. If classified information must exist on mobile or distributed computing equipment, security architects must consider what happens if the entire computer falls into hostile hands. That changes the design problem. You can no longer assume that the motherboard is physically protected. You cannot assume the SSD will remain in the original computer. You cannot assume an attacker will use the normal operating system. And you cannot assume an adversary will stop after an unsuccessful password attempt. The security architecture must continue protecting the classified information even when the attacker controls the physical device. That’s the problem CSfC DAR was designed to address using evaluated commercial technologies.
BitLocker, Trellix, and other commercial encryption technologies can provide strong and appropriate protection for commercial and enterprise information. But the question for classified information isn’t whether those products are “good” or “bad.” It’s whether the complete architecture provides the assurance required for the classified-data threat model. Strong cryptography is necessary. For classified information, cryptography alone isn’t enough. CSfC DAR adds the architectural elements that high-assurance protection demands: evaluated components, approved cryptography, independent protection layers, controlled authentication and authorization, carefully considered key handling, prescribed configurations, and defense in depth. The distinction can be summarized with two questions. Commercial encryption asks: “Is the drive encrypted?” CSfC DAR asks: “If a sophisticated adversary captures this device and defeats one protection mechanism, what still stands between them and the classified data?” For classified data at rest, that’s the question that matters.
BitLocker and other commercial encryption products provide strong protection for everyday enterprise data. But classified information faces a fundamentally different threat, and requires a fundamentally different security architecture. Most modern computers can encrypt their storage. Windows includes BitLocker, security vendors offer full-disk encryption, and many SSDs include built-in encryption. So why isn’t that enough for classified information? The answer comes down to who you are protecting the data from, and what happens if they physically obtain the device. Commercial encryption is generally designed for risks such as lost laptops, stolen drives, unauthorized users, and common cyberattacks. Classified systems must consider a far more capable adversary: a nation-state intelligence service with physical possession of the device, sophisticated laboratories, specialized expertise, significant resources, and potentially months to defeat its protections. For this threat environment, the National Security Agency (NSA) established the Commercial Solutions for Classified (CSfC) program and its Data-at-Rest (DAR) Capability Package. The fundamental difference is this: Commercial encryption is typically a security feature or product. CSfC DAR is a security architecture.
Products such as Microsoft BitLocker provide valuable protection. Properly configured, BitLocker can use strong encryption and a Trusted Platform Module (TPM) to protect against many common lost or stolen device scenarios. But “encrypted” does not automatically mean “approved to protect classified information.” For classified data, security architects must ask deeper questions: Where are encryption keys created and stored? What causes those keys to become available? How is the user authenticated before storage is unlocked? What happens if one security component is compromised? Are encryption layers truly independent? Have components been evaluated for their specific security roles? What happens when an adversary has unlimited physical access to the computer? CSfC addresses these questions at the architecture level, not simply by requiring encryption.
A conventional full-disk encryption product can create a strong cryptographic barrier. But if an attacker finds a way around that barrier, through authentication, key handling, firmware, configuration, or another trusted component, the protected information may become accessible. CSfC DAR uses defense in depth, combining independently protected encryption layers implemented with evaluated components. The objective is straightforward: Compromise of one security layer should not automatically compromise the classified information. This isn’t simply encrypting something twice. Independence matters. If two layers share the same vulnerability, implementation, or point of failure, the second layer provides less protection. CSfC architectures are designed to reduce reliance on any single security boundary.
One important DAR technology is hardware full-drive encryption (HWFDE). With software encryption, encryption and decryption are performed within the host computer environment. A self-encrypting drive, or SED, moves that cryptographic function into the storage device itself. Until properly unlocked, the SSD can keep its underlying information cryptographically inaccessible to the host computer. That creates an important security boundary below the operating system. Removing the SSD and attaching it to another computer shouldn’t reveal its contents. Booting another operating system shouldn’t decrypt it. Bypassing a Windows password shouldn’t, by itself, expose the underlying storage. But hardware encryption alone isn’t sufficient. The encryption engine is only as secure as the mechanism controlling when the drive unlocks.
Think about an extremely strong safe. Its walls may resist drilling, cutting, and physical attack. But imagine that the safe automatically unlocks whenever someone turns on the lights. The strength of the steel suddenly matters much less. A self-encrypting drive without meaningful Pre-Boot Authentication (PBA) can present a similar problem. The drive’s encryption may be exceptionally strong, but if the computer automatically provides what’s necessary to unlock it during startup, an attacker doesn’t necessarily need to defeat the encryption. They can attack the process that causes the safe to open. That’s why encryption and authentication perform different jobs: The Encryption Engine is the safe. Pre-Boot Authentication is the lock. With appropriately implemented PBA, authorization is required before protected storage becomes available for normal operating-system use. This matters because considerable activity has already occurred by the time a normal Windows login screen appears. Firmware has executed, hardware has initialized, and boot components have run. If the storage is already unlocked, an attacker can potentially focus on manipulating that environment rather than attacking the encryption itself. With PBA, physical possession of the computer isn’t sufficient. The attacker must also overcome the authorization mechanism protecting the encrypted storage. This helps explain why CSfC architectures distinguish between the Encryption Engine (EE) and Authorization Acquisition (AA) functions. A strong vault with a weak lock is still a weak security system.
A commercial product and a CSfC solution might both use AES-256. That doesn’t make them equivalent. Modern encryption algorithms such as AES-256 are extraordinarily strong when correctly implemented and when their keys remain protected. A nation-state adversary therefore doesn’t need to brute-force AES. Instead, attackers can look for another path to the data by targeting: authentication and credentials; cryptographic key handling; firmware and boot components; operating-system vulnerabilities; memory containing sensitive information; hardware interfaces; or implementation and configuration weaknesses. The attacker’s question isn’t necessarily: “How do we break AES?” It’s: “What’s the easiest way around AES?” This is why key creation, storage, protection, and authorization are just as important as the encryption algorithm. A better security question is therefore: What must an adversary defeat before classified plaintext becomes available?
Imagine a laptop containing classified information is captured overseas and delivered to a foreign intelligence service. The adversary may have the entire computer, specialized forensic laboratories, hardware and firmware experts, identical devices for experimentation, custom attack tools, and weeks or months to work on the target. They control the physical environment. They can remove the SSD. They don’t have to boot the normal operating system. They can study firmware and hardware interfaces. They can search for implementation weaknesses or ways to obtain credentials or key material. They only need to find the weakest path to the plaintext. This is fundamentally different from the threat model surrounding an ordinary lost corporate laptop. CSfC is designed around that reality.
One of the most important principles behind CSfC is simple: No commercial product should be assumed to be perfect. Software, firmware, and hardware can contain vulnerabilities. Even excellent security products can be misconfigured. Rather than asking a single commercial product to provide every protection necessary for classified information, CSfC combines appropriately evaluated and configured components into a layered architecture. If one independent layer is compromised, another layer is intended to continue protecting the classified information. That’s the power of defense in depth.
| Commercial Encryption | CSfC Data-at-Rest |
| Designed primarily for enterprise threats | Designed for classified national-security data |
| Often one primary encryption boundary | Layered protection architecture |
| Product-focused | Architecture-focused |
| May use strong cryptography such as AES-256 | Combines approved cryptography with architectural requirements |
| May rely heavily on the host OS and TPM | Can establish independent software, authentication, and hardware boundaries |
| Vendor/customer determines configuration | NSA Capability Package defines solution requirements |
| Key protection varies by implementation | Key handling and authorization are addressed within the architecture |
| Primarily addresses enterprise loss, theft, and cyber threats | Accounts for sophisticated adversaries with physical access |
This distinction is particularly important for acquisition officials and program managers. CSfC isn’t simply about purchasing a product from an approved list. The architecture matters. Components must satisfy applicable evaluation requirements, but they also must be selected, combined, configured, provisioned, and operated according to the applicable CSfC Capability Package. Changing an evaluated configuration can change the security assumptions behind it. The protection therefore comes from the complete system: Architecture + evaluated components + correct configuration + operational procedures.
BitLocker, Trellix, and other commercial encryption technologies can provide strong protection for commercial and enterprise information. The question for classified information isn’t whether those products are “good” or “bad.” It’s whether the complete security architecture provides the assurance required against the classified-data threat model. Strong encryption is necessary. For classified information, encryption alone isn’t enough. CSfC DAR adds independent protection layers, evaluated components, controlled authentication and authorization, key-management requirements, prescribed configurations, and defense in depth. The distinction can be summarized with two questions: Commercial encryption asks: “Is the drive encrypted?” CSfC DAR asks: “If a sophisticated adversary captures this device and defeats one protection mechanism, what still stands between them and the classified data?” For classified data at rest, that’s the question that matters.
A CSfC architecture is an NSA-defined approach for protecting classified information using appropriately evaluated commercial components within a prescribed, layered security design. For data at rest, the NSA CSfC Data-at-Rest Capability Package Version 5.1.0 defines approved solution designs, component requirements, authentication, configuration, and implementation guidance.
Commercial Solutions for Classified (CSfC) is an NSA program that enables organizations to protect classified National Security Systems information using commercial technologies. Rather than relying on a single security product, CSfC combines appropriately evaluated components within NSA-defined architectures that specify how encryption, authentication, key management, configuration, and independent protection layers work together.
In a CSfC DAR hardware/software full drive encryption architecture, the hardware layer consists of the encrypted drive plus Pre-Boot Authentication (PBA), which controls authorization before the drive unlocks. The second layer is independent software full drive encryption (FDE), creating another cryptographic boundary that must be overcome before classified data becomes accessible.
Two independent layers reduce reliance on any single security boundary. If one layer is compromised through a vulnerability, configuration problem, authentication weakness, or implementation flaw, another cryptographic barrier remains. Independence also means avoiding shared implementations and common points of failure that could allow one weakness to compromise both layers simultaneously.
No. FIPS validation establishes that a specific cryptographic module has been tested against applicable standards, but it does not establish a complete architecture for protecting classified data. CSfC DAR addresses the broader solution, including component selection, independent protection layers, authentication, key handling, configuration, and operational requirements.
BitLocker provides commercial full drive encryption, but it is not currently listed as a CSfC Data-at-Rest component for this role. A CSfC solution must use components eligible for their specific roles and implement them according to the applicable NSA Capability Package rather than substituting a commercial encryption product based on encryption capability alone.
The NSA CSfC Components List identifies commercial products that have met applicable requirements for specific roles within CSfC solutions. Programs select eligible components from the list and implement them according to the applicable Capability Package. Being listed does not make a product a complete CSfC solution; the architecture and configuration still matter.
A CSfC solution is more than a collection of listed products. Programs must design, configure, document, and register the solution according to the applicable NSA Capability Package and CSfC process. The Authorizing Official remains responsible for accepting the system’s security risk and authorizing its operation within the organization’s mission environment.
CSfC DAR can protect classified data stored on systems where data must remain protected while at rest, including end-user and other DAR-protected devices. The applicable architecture depends on the platform, mission requirements, components, and operating environment, so programs should evaluate the specific system against the solution designs defined in the current DAR Capability Package.
Start by identifying where classified data is stored, what happens if the platform is lost or captured, and how storage is currently encrypted and authenticated. Then compare the existing architecture, components, authentication, and encryption layers against the NSA CSfC Data-at-Rest Capability Package and determine where the platform differs from an approved solution design.
Evaluate how your current data-at-rest architecture aligns with NSA CSfC requirements. Take the Cigent CSfC DAR Readiness Assessment to identify potential gaps in your encryption, authentication, and layered protection approach and determine your next steps.
Take the CSfC DAR Readiness Assessment
Brett Hansen has 30 years of IT experience. Prior to joining Cigent, held leadership positions with companies providing SaaS data solutions. He was also an executive at Dell for over a decade overseeing Client Software organization including developing and leading Dell Data Security business that provided integrated hardware and software security solutions. Brett started his career with IBM holding leadership positions with various software organizations focusing on IT management, development, and security.
