Skip to main content
Comply Defense
Category: Classified Information Management

Capability Package

Also known as: CP, CSfC Capability Package, NSA Capability Package
Simply put

A Capability Package is a document published by the National Security Agency (NSA) that describes, in vendor-neutral terms, how to build an approved solution for protecting classified information using commercial products. Rather than naming specific products, it lays out the overall design of a solution along with the security and configuration requirements an organization must meet. Capability Packages are associated with NSA's Commercial Solutions for Classified (CSfC) program, and readers should consult the current NSA-published versions and annexes for authoritative requirements.

Formal definition

Within NSA's Commercial Solutions for Classified (CSfC) program, a Capability Package (CP) is a set of vendor-agnostic, solution-level specifications published by the National Security Agency that defines a system-level solution framework and documents the security and configuration requirements customers and integrators must satisfy to protect classified information. CPs are product-neutral and describe general solution architectures, such as protecting classified data as it traverses an untrusted network or protecting data at rest, rather than prescribing particular commercial products; product-specific configuration detail is generally addressed through associated annexes. NSA maintains and releases CPs and annexes under a defined implementation and release schedule, and CPs are versioned (for example, the CSfC Data-at-Rest Capability Package has been issued in successive revisions), so practitioners should verify the currently published CP version and its annexes against NSA's authoritative CSfC materials. This entry describes the concept of the CP and does not cover the full certification, registration, or solution-approval process, product selection, or the classification-handling and accreditation requirements that apply to the resulting solution, all of which must be confirmed against current NSA guidance and applicable national security system authorities.

Why it matters

Capability Packages sit at the center of NSA's Commercial Solutions for Classified (CSfC) program, which allows organizations to protect classified information using layered commercial products rather than waiting for purpose-built government cryptographic equipment. For programs operating on tight timelines or seeking greater flexibility in commercial technology refresh cycles, the CP is the authoritative starting point that defines what an approved solution must look like at the architectural level. Without adhering to a current Capability Package, an integrator has no sanctioned framework for assembling commercial components into a solution NSA will recognize as suitable for classified data.

Because CPs are vendor-neutral and describe general solution architectures, such as protecting classified information as it travels across an untrusted network, or protecting classified data at rest, they establish a common baseline of security and configuration requirements that customers and integrators must satisfy. This separation of solution design from specific product selection is deliberate: it lets NSA maintain the security framework independently of the commercial products that come and go beneath it, with product-specific detail generally handled through associated annexes.

A common and consequential mistake is treating a Capability Package as static reference material. NSA maintains and releases CPs and annexes under a defined implementation and release schedule, and CPs are versioned through successive revisions. Building to a superseded version, or overlooking the annexes that accompany a CP, can leave a solution out of alignment with current requirements. Practitioners should also recognize that meeting a CP's design and configuration requirements is only one part of fielding a classified solution, it does not by itself resolve the certification, registration, solution-approval, or accreditation obligations that apply under national security system authorities.

Who it's relevant to

Solution integrators and system architects
Integrators assembling commercial products into solutions for classified information rely on Capability Packages as the vendor-neutral design and requirements baseline. They must work from the current published CP version and its annexes, since the CP defines the system-level framework and the security and configuration requirements the assembled solution must meet.
Information system security managers and security engineers
Personnel responsible for the security posture of systems handling classified data use CPs to understand the general solution architecture and the configuration requirements that apply. They should treat the CP as one input into a broader process and confirm certification, approval, and accreditation obligations separately against current NSA and national security system authorities.
Program and acquisition offices for national security systems
Offices planning solutions that protect classified information, whether protecting data in transit across untrusted networks or data at rest, need to account for the applicable Capability Package and NSA's release schedule for CPs and annexes when scoping timelines, since CPs are versioned and requirements evolve across revisions.
Compliance officers and assessors supporting classified solutions
Those verifying that a solution aligns with CSfC expectations use CPs to identify the security and configuration requirements against which a solution is measured. They should distinguish between meeting a CP's requirements and completing the separate certification, registration, and solution-approval steps, and should always confirm the currently published CP version against NSA's authoritative materials.

Inside CP

Solution Architecture Requirements
A Capability Package generally defines the reference architecture and required components for building an approved solution, describing how discrete products are integrated to meet a specific protection objective rather than specifying a single vendor product.
Configuration and Implementation Guidance
CPs typically include detailed configuration requirements, deployment constraints, and implementation instructions that an integrator must follow so that the fielded solution matches the approved design.
Testing and Compliance Requirements
A CP commonly specifies testing procedures, validation criteria, and compliance activities that must be completed and documented to demonstrate the solution meets the stated security requirements.
Risk and Threat Assumptions
CPs generally articulate the threat model and residual risk considerations underlying the design, clarifying what the capability is intended to protect against and the assumptions on which its protections depend.
Registration or Approval Process
In most implementations, a CP describes the process by which an implemented solution is registered with or approved by the governing authority, which the reader should verify against the current authoritative text for the specific program.

Common questions

Answers to the questions practitioners most commonly ask about CP.

Is a Capability Package the same as an Authority to Operate (ATO)?
No. A Capability Package is a set of requirements, configuration guidance, and reference architectures that describes how to build and implement a particular solution, whereas an ATO is a formal, time-bound authorization decision issued by an Authorizing Official permitting a system to operate. Implementing a Capability Package does not by itself confer authorization; the resulting system must still go through the applicable assessment and authorization process, and any authorization remains subject to continuous monitoring. Verify the specific relationship between a given Capability Package and any authorization requirement against the current authoritative source.
Does following a Capability Package mean my solution is automatically compliant and secure?
Not necessarily. A Capability Package generally provides prescriptive requirements and design guidance, but adherence to that guidance is distinct from both compliance and security. Compliance is demonstrated through assessment against applicable controls and requirements, and security depends on correct implementation, operation, and ongoing monitoring. Meeting a Capability Package's stated requirements should be treated as one input to a broader assessment and authorization effort, not as evidence that the deployed solution is fully compliant or secure. Confirm the current requirements and how conformance is evaluated against official sources.
How do I determine which version of a Capability Package applies to my implementation?
Capability Packages are typically issued and revised over time, and requirements can change between revisions. You should identify the specific Capability Package and revision that governs your solution type, confirm whether it is the current applicable version, and check for any supplements, annexes, or errata. Because version applicability can carry program- or agency-specific interpretations, verify the governing revision directly with the issuing authority or program office rather than relying on a prior version.
What documentation should I maintain to show conformance with a Capability Package?
In most implementations you would maintain records mapping your design and configuration to the Capability Package's stated requirements, along with supporting artifacts such as architecture diagrams, configuration baselines, and evidence of testing. The precise documentation set can depend on the applicable assessment and authorization process and any program-specific expectations. Confirm the required artifacts and their format against the current authoritative guidance, since this entry does not cover implementation- or contract-specific documentation requirements.
How does a Capability Package fit into the assessment and authorization workflow?
A Capability Package generally informs the design and build phase by specifying requirements and reference architectures, but it does not replace the assessment or authorization steps. The implemented solution would still undergo assessment against applicable controls, and an Authorizing Official would make any authorization decision separately. Treat the Capability Package as guidance that feeds into, rather than substitutes for, the governing assessment and authorization process. Verify the specific workflow against current official sources.
Do updates to a Capability Package affect a solution that is already deployed?
They can. Because Capability Packages are periodically revised, changes may introduce new or modified requirements that affect existing deployments, particularly where continuous monitoring or reauthorization is involved. You should track revisions to the applicable Capability Package and assess the impact of any changes on your deployed solution. Confirm how and when updated requirements apply to fielded systems with the issuing authority or program office, as this may vary by program and is out of scope for this general entry.

Common misconceptions

A Capability Package is itself an authorization or Authority to Operate (ATO).
A CP defines the requirements and architecture for building an approved solution; it is not an authorization decision. Fielding a compliant solution still generally involves separate assessment, registration, or authorization steps, and any resulting approval is typically time-bound and subject to continuous monitoring rather than permanent.
Following a Capability Package guarantees the solution is secure.
Compliance with a CP is not the same as security. A CP establishes a baseline design and requirements, but proper implementation, ongoing configuration management, and continuous monitoring remain necessary, and residual risk depends on the assumptions and threat model stated in the CP.
A Capability Package is a fixed document that does not change.
CPs are generally revised over time as threats, technologies, and governing guidance evolve. Practitioners should confirm they are working from the current applicable revision rather than an outdated version.

Best practices

Confirm you are referencing the current applicable revision of the Capability Package and verify its requirements against the governing authority's official text before beginning design or implementation.
Follow the CP's configuration and implementation guidance precisely, documenting any deviations so they can be reviewed against the approved architecture.
Complete and retain evidence for all specified testing and compliance activities to demonstrate the fielded solution matches the approved design.
Treat any resulting approval or registration as time-bound, and establish continuous monitoring to sustain the solution's compliance and security posture over time.
Validate that the CP's stated threat model and risk assumptions align with your operational environment, and address any residual risk not covered by the package.
Do not assume a compliant CP-based solution satisfies requirements outside its stated scope; confirm additional contractual, program, or agency-specific obligations against current authoritative sources.