Skip to main content
Comply Defense
Category: Classified Information Management

Data-at-Rest (DAR) Capability Package

Also known as: DAR CP, CSfC Data-at-Rest Capability Package, Data-at-Rest CP
Simply put

The Data-at-Rest (DAR) Capability Package is one of the Capability Packages under the NSA's Commercial Solutions for Classified (CSfC) program, and it focuses on protecting classified data while it is stored (at rest) on a device or system. It provides guidance for using commercial products, layered together, to encrypt that stored data so it stays protected if the device is lost or stolen. It applies specifically to information stored on an End User Device (EUD) or protected system rather than data being transmitted across a network.

Formal definition

The DAR Capability Package is a CSfC design guidance document that specifies how to combine independent, commercially available cryptographic layers to protect classified data at rest on End User Devices (EUDs) or protected systems. In most implementations it generally requires two nested, independent layers of encryption so that stored data is encrypted more than once, meeting the assurance requirements for protecting classified DAR. The capability described here is version 5.0 as referenced in the evidence; because CSfC Capability Packages are revised over time, practitioners should verify the current applicable version and its specific component, authentication, and configuration requirements against the official CSfC/NSA source. This entry does not cover product-specific listings, implementation registration, or accreditation steps, which must be confirmed against current authoritative CSfC guidance.

Why it matters

Classified information stored on portable and fixed devices represents a persistent risk that traditional network defenses do not address: if an End User Device is lost, stolen, or physically captured, the data on it can be compromised regardless of how well the network perimeter was protected. The DAR Capability Package matters because it gives organizations a government-recognized design approach for protecting classified data at rest using commercially available products rather than requiring purpose-built government cryptographic equipment. This can shorten acquisition timelines and broaden the range of devices that can be used to handle classified information, while still meeting the NSA's assurance expectations.

The core reason the DAR CP holds a high bar is its reliance on layered encryption. As referenced in the evidence, the package is designed to ensure that data is encrypted not once but twice, using independent commercial cryptographic layers. This defense-in-depth model reflects a fundamental principle: a single encryption implementation may contain flaws, misconfigurations, or vulnerabilities, and relying on one layer alone is generally considered insufficient for classified information. Two nested, independent layers mean that the failure or compromise of one layer does not by itself expose the protected data.

Practitioners should be careful not to treat conformance with the DAR CP as a one-time or permanent achievement. CSfC Capability Packages are revised over time, the evidence references version 5.0, and component, authentication, and configuration requirements can change across revisions. Following the design guidance also does not, on its own, address product listing, solution registration, or accreditation obligations, which are separate steps that must be confirmed against current authoritative CSfC/NSA sources.

Who it's relevant to

Information System Security Managers and Engineers
ISSMs and security engineers responsible for systems that store classified information use the DAR CP as design guidance when architecting solutions built from commercial products. They are responsible for ensuring the two independent cryptographic layers are correctly selected and configured against the applicable version of the package, and for confirming that the approach they follow reflects current CSfC requirements rather than a superseded revision.
Program Managers and Acquisition Personnel
Those planning solutions that must protect classified data on End User Devices may look to the DAR CP as a path to using commercially available products instead of purpose-built government cryptographic equipment. They should account for the fact that following the design guidance is separate from product listing, registration, and accreditation activities, which must be verified against authoritative CSfC sources.
Vendors and Product Providers
Commercial vendors seeking to have their products used within DAR CP solutions need to understand the requirements for serving as an approved independent cryptographic layer. The layered, defense-in-depth model means a product typically functions as one of two nested layers, and vendors should track revisions to the Capability Package that may affect component or configuration requirements.
Authorizing Officials and Assessors
Personnel who evaluate or authorize systems handling classified data at rest reference the DAR CP to confirm that layered encryption and other assurance requirements are met. They should distinguish between conformance with the design guidance and the separate accreditation decisions, and should verify that assessments are based on the current applicable version of the package.

Inside DAR CP

Capability Package (CP) Framework
A Data-at-Rest Capability Package generally refers to a structured set of design guidance, requirements, and configuration criteria for protecting data stored on a device or media through commercial encryption solutions. Such packages are commonly associated with the NSA Commercial Solutions for Classified (CSfC) program; readers should verify the current version and applicability against the official NSA CSfC source, as the specific requirements are revised over time.
Layered Encryption Approach
DAR guidance under the CSfC model typically emphasizes two independent, layered commercial encryption components so that the compromise of a single layer does not expose the protected data. The precise composition of the layers and approved product combinations should be confirmed against the applicable published CP revision rather than assumed.
Components List Dependency
Implementations built to a Capability Package generally must use products drawn from an associated approved products or Components List maintained under the governing program. Product eligibility can change across revisions, so practitioners should verify current listings before selecting hardware or software.
Registration and Compliance Process
Solutions following a CSfC Capability Package commonly require a registration or approval step with the sponsoring authority, distinct from an accreditation or authorization of the broader information system. The exact process and required artifacts should be confirmed against current program documentation.
Scope: Data While Stored
DAR protections address the confidentiality of data while it is at rest on media or a device, as distinct from Data-in-Transit protections that address data moving across networks. The two are separate concerns and, where both apply, are typically addressed by different guidance.

Common questions

Answers to the questions practitioners most commonly ask about DAR CP.

Does implementing a Data-at-Rest (DAR) Capability Package by itself make a system compliant or authorized to operate?
No. Following a DAR Capability Package addresses one aspect of protecting data when it is stored, but implementation of a capability package is not the same as achieving compliance across a control baseline, nor is it equivalent to an authorization. Compliance and security are distinct concepts, and an Authority to Operate (ATO) is granted through a separate risk-based authorization decision. You should confirm how DAR protections map to the applicable control set and authorization requirements against current authoritative sources.
Is a Capability Package a binding regulation that I am legally required to follow?
Not in the same way a regulation or contract clause is. A capability package generally functions as guidance describing an approach for meeting a protection objective, and its binding effect depends on how it is incorporated into your agency, program, or contractual requirements. Whether it applies to your system, and in what form, is something you must verify against the governing publication and your specific obligations rather than assuming it is universally mandatory.
How does a DAR Capability Package relate to the control baseline I am already implementing?
A DAR Capability Package is generally intended to support, not replace, an applicable control baseline. In most implementations you would map the capability package's protections to the relevant controls in your baseline and document how they satisfy the associated requirements. Because baselines and tailoring vary across revisions and agencies, you should confirm the specific mappings against the current authoritative text for your environment.
What should I document to show a DAR Capability Package has been implemented?
Documentation should generally capture how the selected components and configurations meet the capability package's stated objectives, along with how those protections align to your applicable controls. This typically feeds into your system security documentation and supports assessment activities. The exact artifacts expected can differ by agency and authorization process, so verify the required documentation against your governing guidance.
Does a DAR Capability Package cover data in transit or data in use?
As the name indicates, a DAR Capability Package addresses data at rest, meaning data in storage, and does not by itself address protections for data in transit or data in use. Those states are typically governed by separate protection approaches. You should confirm which capability packages or requirements apply to each data state in your environment rather than assuming a single package covers all of them.
Once I implement a DAR Capability Package, are the protections a one-time task?
No. Protections implemented under a capability package generally need to be maintained, monitored, and reassessed over time, consistent with continuous monitoring expectations. Configurations, components, and the underlying guidance can change across revisions, so treating implementation as a one-time effort is a common mistake. Verify ongoing maintenance and revision requirements against the current authoritative sources.

Common misconceptions

Deploying a Data-at-Rest Capability Package by itself authorizes a system to operate or handle classified information.
A Capability Package generally provides design and configuration guidance and, where applicable, a registration pathway. It is not equivalent to an Authority to Operate (ATO) and does not replace the applicable authorization process (for example, under the RMF for DoD or national security systems). Assessment and registration are distinct from authorization, which remains a separate, time-bound determination subject to continuous monitoring.
Following a DAR Capability Package makes a system fully compliant and therefore secure.
Compliance with a Capability Package is not the same as overall security. The CP addresses data-at-rest protection within its defined scope and does not cover other control areas, operational security practices, or requirements from separate frameworks. Readers should confirm which additional obligations apply to their system category and data type.
Data-at-Rest and Data-in-Transit protections are interchangeable, so meeting one satisfies the other.
These address different states of data and are governed by separate guidance. Protecting stored data does not satisfy requirements for data moving across networks, and vice versa; where both states are in scope, each must be addressed on its own terms.

Best practices

Obtain and work from the current, official revision of the applicable Capability Package, since requirements and approved product combinations are updated over time.
Verify that every encryption component is drawn from the current approved products or Components List associated with the governing program before procurement or deployment.
Preserve the intended layering of independent encryption components rather than substituting a single layer, and confirm approved combinations against the published guidance.
Treat any required registration or program approval as distinct from system authorization, and pursue the applicable authorization process (such as the RMF for DoD or national security systems) separately.
Confirm the data type and system category in scope (for example CUI versus classified) so that the correct additional obligations and any agency-specific tailoring are identified.
Where both stored and transmitted data are in scope, address Data-at-Rest and Data-in-Transit protections separately using their respective guidance, and consult current official sources to confirm implementation and contractual specifics.