CSfC Capability Packages and What Each One Requires

CSfC Capability Packages are the NSA’s published blueprints for building classified-data protection out of commercial products. The Components List tells you which products are eligible; the Capability Package tells you what a valid solution built from them must look like, which component categories it needs, how the layers compose, how they must be configured, and what independence between them means.

A Capability Package is best read as encoded risk logic rather than paperwork: every requirement in it maps to a way stored classified data can actually be lost. Teams that meet the package late discover that at the worst moments, an authorization review if the gap is caught there, a captured device if it is not. Teams that read it first build systems shaped for both.

This article walks the four packages, what each exists to protect, how to actually read one, and then goes deep on the one that governs stored classified data, the Data at Rest Capability Package, because that is where most fielded hardware lives. For the program vocabulary around all of this, listing, registration, authorization, the CSfC pillar guide is the reference.

Key Takeaways

• A Capability Package is an architecture specification, not guidance: it defines required component categories, layer composition, configuration requirements, and independence rules for one class of CSfC solution. Solutions are registered against a specific package and version.
• There are four: Mobile Access, Campus WLAN, Multi-Site Connectivity, and Data at Rest. Each addresses a different place classified data lives or moves, and a program picks the package that matches its problem.
• The Data at Rest package assumes the device is gone: the applicable DAR Capability Package is written for hardware outside your control, lost, seized, or captured, and requires protection that holds with no network, no management reach, and no friendly hands.
• Two independent layers is the DAR core requirement: an outer layer of hardware full drive encryption gated by Pre-Boot Authentication, and an inner layer of independent software full drive encryption. The drive plus its PBA is one layer.
• Version discipline is compliance: packages are revised, registrations attach to versions, and an architecture built from memory of an old package is an architecture built wrong. Check the current version at design time and at registration.

What Is a CSfC Capability Package?

A Capability Package is NSA’s published specification for one class of Commercial Solutions for Classified solution. It is the document that converts a shelf of eligible components into a defined architecture: which component categories are mandatory, how the two independent layers must be composed, what configuration requirements apply to each, and what the solution must demonstrate about key management, authentication, and administration.

Two properties make a Capability Package different from ordinary security guidance. First, it is prescriptive: the requirements inside it are the protection the data actually gets, and the surface an assessor checks, not a menu of options. Second, it is versioned: a solution is registered with NSA against a specific package version, which means “we follow the DAR CP” is an incomplete sentence until it ends with a number, currently the applicable version for data at rest.

The packages are published by NSA on the CSfC Capability Packages page, publicly, which is one of the program’s quiet strengths: the architecture your Authorizing Official will measure you against is not a secret, and there is no excuse for discovering it late.

The Four Capability Packages

The direct answer: one package per place classified data lives or moves, four in total.

• Mobile Access (MA) covers classified connectivity from mobile end user devices, the architecture that lets a device in the field reach classified networks through layered commercial encryption, typically nested VPN layers.
• Campus WLAN covers classified wireless networking within a facility, layering commercial wireless and VPN components so a campus network can carry classified traffic.
• Multi-Site Connectivity (MSC) covers classified links between sites, protecting data in transit across infrastructure the program does not control.
• Data at Rest (DAR) covers classified data stored on end user devices and systems, protecting data when the hardware itself is powered off, unauthenticated, or out of your hands.

The first three are fundamentally about data in motion, and their threat model assumes an adversary on the wire. The fourth is about data that is not going anywhere, and its threat model assumes an adversary holding the hardware. That difference in assumption is why the DAR package reads differently from the other three, and why solutions for it live or die on what the drive does before anything else boots.

Programs sometimes need more than one package; a deployable kit might carry an MA solution for connectivity and a DAR solution for its storage. The packages compose, but each solution is built, registered, and assessed against its own.

How to Read a Capability Package

The answer, in the order that saves the most time:

1. Confirm the version first. Everything downstream depends on it. Registrations attach to versions, revisions change requirements, and the version on NSA’s site today is the one your solution will be measured against.
2. Map the required component categories to the Components List. The package names the categories a solution needs; the list tells you which products qualify for each. This pairing is the whole design space, and the five-minute verification habit from the Components List guide applies to every component you shortlist.
3. Read the composition and independence requirements as hard constraints. How the layers stack, what independent means, what each layer must enforce on its own. These are where architectures fail review, because they are where teams substitute intuition for the text.
4. Treat the configuration requirements as the assessment checklist. Authentication enforcement, key handling, administration. These are where protection quietly holds or fails on the device itself; an assessor reads them that way, and so should the design team, so nothing in the field or at authorization is a surprise.

The common failure mode is reading the package as background and the product datasheets as the plan. The package is the plan. Products are how you satisfy it.

The Data at Rest Capability Package, What the applicable version Demands

The DAR Capability Package the applicable version governs classified data stored on end user devices and systems, and its core demand is two independent encryption layers, each enforcing its own authentication, composed so that a failure in one layer need not compromise the other.

In the architecture Cigent supports, the layers are:

• The outer layer: hardware full drive encryption with Pre-Boot Authentication. A CSfC-listed self encrypting drive encrypts stored data in hardware using an implementation-specific algorithm, often AES-256, and the PBA runs in its own environment before any operating system loads, requiring validated credentials before access to protected storage is enabled. The drive is the safe and the PBA is the lock, and together they are one layer. Counting them as two is the most common error in DAR designs, and it leaves a program a single flaw away from exposure.
• The inner layer: independent software full drive encryption. A second encryption of the same data, with separate cryptographic libraries and distinct key management, enforcing its own authentication after the outer layer unlocks.

Independence is the requirement doing the real work. The layers exist so that a vulnerability in one implementation, a drive firmware flaw, a software defect, a compromised component, still leaves the adversary facing a second, differently built barrier. Layers that share machinery share failure modes, which is why the inner layer’s separate cryptography and key management is a requirement rather than a preference.

The package’s threat model is worth internalizing because it explains every requirement in it: the device is assumed to be gone. No network defense applies, no management server is reachable, and the adversary has time and tooling. Protection either lives on the device and enforces itself, or it does not exist. That is also why end-of-life matters inside the same architecture: verified sanitization aligned with NIST SP 800-88 Rev. 2 is how a program proves a decommissioned or unrecoverable drive carries nothing worth recovering.

Where the Package Meets Real Hardware

A Capability Package is platform-agnostic on purpose, and real programs have to land it on real machines: operator laptops, deployable servers, vehicle compute, unmanned platforms. The composition does not change across them, outer layer, inner layer, independence, but the form factors and deployment mechanics do, which is why the architecture is laid out across client, enterprise, and embedded environments on the data at rest protection solution page.

Cigent and Curtiss-Wright PacStar have collaborated on data-at-rest protection for rugged tactical edge systems. The public case study describes layered protection and Pre-Boot Authentication; exact component versions, solution registration, and the complete encryption-layer configuration should be confirmed before making deployment-specific claims.

Why it worked: the package did the arguing in advance. Because the architecture was composed to a published specification from listed components, the program’s authorization conversation was about configuration and operation rather than about whether the design itself was sound.

The Capability Packages

Capability Packages are where CSfC stops being a vocabulary lesson and becomes an engineering specification. Four packages cover the four places classified data lives or moves, each is prescriptive and versioned, and the one governing stored data, the the applicable DAR Capability Package, demands two independent encryption layers built for the day the hardware is in the wrong hands.

Read the package before the datasheets, confirm the version before the design, and count the layers the way an assessor will: the drive and its Pre-Boot Authentication are the outer layer, one layer, and independent software encryption is the inner. Programs that arrive at authorization with that arithmetic already correct tend to leave with a signature, and, more to the point, they field systems whose data survives the day the hardware does not come back.

The fastest way to see where your platforms stand against the package is the CSfC DAR Assessment: a few minutes mapping your data and systems against the two-layer requirement, with a clear read on which layer your current stack covers and what fills the gap.

Frequently Asked Questions

What is a CSfC Capability Package?

A Capability Package is NSA’s published architecture specification for one class of Commercial Solutions for Classified solution. It defines required component categories, how the independent layers compose, and the configuration requirements a valid solution must meet. Solutions are registered with NSA against a specific package version.

How many CSfC Capability Packages are there?

Four. Mobile Access covers classified connectivity from mobile devices, Campus WLAN covers classified wireless within a facility, Multi-Site Connectivity covers classified links between sites, and Data at Rest covers classified data stored on devices and systems. Each addresses a different place classified data lives or moves.

What does the Data at Rest Capability Package require?

The applicable version requires two independent encryption layers protecting stored classified data. In the common architecture, the outer layer is hardware full drive encryption gated by Pre-Boot Authentication and the inner layer is independent software full drive encryption with separate cryptography and key management, each enforcing its own authentication.

Does the drive plus pre-boot authentication count as two layers?

No. The drive and its Pre-Boot Authentication together form the outer layer, one layer, because the PBA is the hardware layer’s enforcement mechanism rather than an independent barrier. The second layer must satisfy the applicable Capability Package independence and component requirements. Counting drive plus PBA as two is the classic DAR design error.

Which Capability Package applies to laptops and servers carrying classified data?

The Data at Rest Capability Package. It governs classified data stored on end user devices and systems, laptops, workstations, servers, and embedded platforms alike, and its requirements apply wherever the data physically rests, including deployable and tactical hardware operating outside controlled facilities.

Are Capability Packages public?

Yes. NSA publishes them on the CSfC program site, along with the Components List. The architecture a solution will be assessed against is openly available, which means program teams can, and should, design to the current published package rather than discovering its requirements during authorization.

Why do Capability Package versions matter?

Because solutions are registered against a specific version and revisions change requirements. An architecture designed from an outdated package can miss current requirements, and a registration must reflect the version actually implemented. Confirm the current version at design time and again at registration.

What does layer independence mean in the DAR package?

It means the two encryption layers are designed to reduce common-mode failure risks: separate cryptographic implementations and distinct key management, each enforcing its own authentication. A vulnerability in one layer then still leaves data protected by the other, which is the entire risk logic of the two-layer design.

Can one program need more than one Capability Package?

Yes. A deployable kit might implement Mobile Access for classified connectivity and Data at Rest for its storage. The packages compose within a program, but each solution is designed, registered, and assessed against its own package, with its own components and configuration requirements.

Where do CSfC components fit into a Capability Package?

The package names the component categories a solution requires; the NSA CSfC Components List identifies which commercial products are eligible for each category. For data at rest, that means listed hardware full drive encryption for the outer layer and listed software full drive encryption for the inner.