Writing a Crypto-Agility Policy: What to Actually Include

What to include in a crypto-agility policy for regulatory compliance and a mature crypto-agility program

The goal of a crypto-agility policy is to codify the processes by which the organization changes its cryptographic algorithms as needed. This goes well beyond a list of approved algorithms to include the processes, stakeholders, and approvers, and the compensating controls for when a system or application can't make a required change.

NIST CSWP 39 defines four tiers of readiness. For crypto-agility policies, the first three are:

Tier 1: No formal policy
Tier 2: Management-approved policy isn't consistently adopted across the organization
Tier 3: Policy is defined, implemented, reviewed, and assessed

A cryptographic policy is more than just a "nice to have." Several regulations already mandate these types of policies.

What NIST CSWP 39 Says About Crypto-Agility Policies

NIST's CSWP 39 specifies that crypto-agility should be built into an organization's cryptographic policies. This should happen during the design and development of systems and include technology acquisitions, replacements, and modernization.

Additionally, this policy should be translated into machine-consumable configuration files that can be deployed by automated tools. This helps to ensure policy enforcement, addressing the Tier 2 gap of a policy that isn't adopted consistently.

Regulatory Requirements for Crypto-Agility Policies

Several regulations (NIS2, Implementing Regulation 2024/2690, and DORA) explicitly mandate that an organization have cryptographic policies. Additionally, these often require organizations to have certain capabilities that map to a mature crypto-agility program.

Regulation	Who it covers	What it requires
NIS2, Article 21(2)(h)	Essential and important entities in the EU	Policies and procedures on the use of cryptography and, where appropriate, encryption
Implementing Regulation (EU) 2024/2690, Annex §9	Certain digital infrastructure and ICT service providers	A cryptography policy that sets approved algorithms and cipher strength "following, where appropriate, a cryptographic agility approach," plus a key management lifecycle
DORA RTS 2024/1774, Articles 6–7	EU financial entities	A cryptography policy with provisions for updating or changing cryptographic technology as cryptanalysis develops, and mitigation where updating isn't possible
PCI DSS v4.0.1, Req. 12.3.3	Entities in PCI scope	An inventory, monitoring, and a documented response strategy for cryptographic vulnerabilities
Quantum Computing Cybersecurity Preparedness Act (6 U.S.C. §1526), OMB M-23-02, EO 14412, NSM-10	U.S. Federal agencies	A cryptographic inventory and migration to PQC. EO 14412 sets post-quantum key establishment by Dec 31, 2030 and signatures by Dec 31, 2031 for high-value assets.
EU Cyber Resilience Act (Regulation 2024/2847)	Manufacturers of products with digital elements sold in the EU	State-of-the-art encryption and security updates (Annex I). Full application is December 11, 2027.
MAS advisory (February 2024) and TRM Guidelines §10	Singapore financial institutions	MAS expects crypto-agility. This is guidance, not binding rules.

Many organizations are subject to at least one regulation or standard that requires a cryptographic policy or related capabilities. Mapping policies to regulatory requirements simplifies compliance and helps to develop evidence for audits.

What Should a Crypto-Agility Policy Include?

A crypto-agility policy should both meet regulatory requirements and the needs of a corporate crypto-agility program. Essential components include:

Scope: The policy should explicitly define its scope. Ideally, this is all usage of cryptography within the organization, including protocols, applications, libraries, hardware, firmware, third-party apps, and the cloud.
Roles and Decision Rights: Explicit role definitions are essential to ensure that the policy is maintained and enforced. This includes overall ownership, control over algorithm approval and deprecation, and ownership of cryptographic keys.
Algorithm and Parameter Rules: These rules define the criteria for approved, deprecated, and disallowed algorithms. This may also cover use cases, such as allowing otherwise-deprecated algorithms for decrypting stored data.
Selection Criteria: Selection criteria are used to select new algorithms and libraries for approval. Considerations might include maturity, standardization, library support, and validation status. For post-quantum cryptography (PQC), hybrid vs. pure PQC may be a jurisdiction-specific decision.
Implementation Requirements: These define the rules for using cryptography within the organization. For example, crypto APIs should be used instead of hardcoding algorithms, keys, or sizes.
Acquisition and Design: Crypto-agility should be a consideration when acquiring solutions or designing a new application or architecture. For example, cryptographic component lists and PQC readiness might be included in the procurement process and contractual terms.
Inventory and Monitoring: A comprehensive, up-to-date CBOM is essential for quantum readiness and crypto-agility. The policy should define processes for CBOM upkeep, annual reviews (for PCI compliance), and monitoring for significant events (such as deprecated algorithms or Q-Day timelines).
Key and Certificate Lifecycle: Organizations should be able to automatically rotate cryptographic keys and digital certificates periodically and in response to certain events. For example, an event like the eMudhra incident could trigger certificate rotation or migration.
Change Management: Algorithm deprecation or disallowal should be controlled by a structured change management process. However, emergency paths should also exist to enable rapid response to key compromise or CA distrust events.
Exceptions: Some cryptographic usage may not be able to comply with corporate policies. Exceptions should be carefully managed with compensating controls to limit risk (such as the use of a crypto gateway for legacy technology).
Training, Measurement, and Reporting: Developers should be trained on policies and best practices. Organizations can also measure policy effectiveness via KPIs such as effort to migrate and executive reporting.

Common Mistakes When Creating a Crypto-Agility Policy

Some common pitfalls that organizations may encounter when building a crypto-agility policy include:

Embedding Algorithms Lists in the Policy: A crypto-agility policy should be subject to a strict change management and approval process. Embedding the list of approved algorithms means the entire policy needs to be re-approved each time an algorithm is added or deprecated.
No Named Owner: NIST CSWP 39 calls for identifying a responsible official to lead a crypto-agility program. Ownership of the program as a whole and its various elements (such as individual keys or digital certificates) should be clearly defined.
No Exceptions Process: Legacy systems and other edge cases might make it impossible for an organization to achieve 100% compliance. Without an exceptions process, teams might just ignore the policy entirely.
Vague Requirements: "Use strong cryptography" is a good idea but too vague to be easily enacted or enforced. A policy should define clear criteria for approving or disallowing cryptographic algorithms for use in the business.
PQC-Only Focus: Quantum migration is a primary driver for crypto-agility, but organizations also need to be ready for non-quantum triggers of algorithm deprecation. A crypto-agility policy should cover all of an organization's cryptographic usage.
Rendering Data Unreadable: Old data may be encrypted by an algorithm that is insecure and banned for other purposes. Deprecated algorithms may be marked as "read only" for backward compatibility, potentially with data re-encrypted with a secure algorithm upon access.
No Procurement Support: A significant portion of an organization's cryptographic usage likely involves third-party applications. A policy should include links to procurement processes and contracts.
Copy-Pasting a Template: A template can be a great starting point for a crypto-agility policy. However, it needs to be tailored to an organization to be effective.

FAQs

Do we need a separate crypto-agility policy, or can we extend our existing encryption policy?

Extending an existing policy is often faster and easier, especially since NIS2 and DORA already require one. This policy should be expanded to explicitly include crypto-agility requirements, such as processes and criteria for approving or deprecating algorithms.

Should the policy list approved algorithms?

Generally, no. The policy as a whole should undergo a strict change management and approval process and change rarely. Approved algorithms may change quickly and more regularly, so including it in the policy will introduce additional, unnecessary overhead. Where a regulation requires the policy to establish approved algorithms (such as Implementing Regulation (EU) 2024/2690), the policy can reference a maintained standard; confirm this with your auditor.

Who should own it?

Ownership should be assigned to a particular role and may be split across multiple roles. For example, in CSWP 39's crypto API discussion, the CISO sets policy, while system administrators implement it.

How is it different from a key management policy?

The two overlap, and a key management policy may be a subset of or companion document to the crypto-agility policy. The crypto-agility policy covers factors such as algorithm approval and deprecation, which are beyond the scope of key management.

What about systems that can't comply?

Systems that can't comply should be documented and managed via compensating controls. For example, legacy hardware and systems may be protected by a crypto gateway that implements more modern algorithms.

How often should it be reviewed?

Reviews should be performed at least annually and as needed in response to significant events. For example, a major algorithm deprecation, library CVE, CA distrust event, or new regulation could require policy changes.