Crypto Agility: What It Means and How to Achieve It

The answer, up front

Crypto agility is the ability to replace cryptographic algorithms without disrupting operations. You achieve it by keeping algorithm choices in configuration instead of code, using libraries with pluggable providers, designing protocols that negotiate algorithms, and running key management that holds both classical and post-quantum keys 1, 2.

Last verified: Sep. 30, 2026.

What crypto agility means

NIST defines crypto agility as "the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations" 1. Canada's Cyber Centre gives a shorter version: algorithms used in applications and protocols can be interchanged easily, so systems stay secure when new vulnerabilities appear 3.

Post-quantum migration makes this urgent for a plain reason. Standards keep moving. NIST selected HQC in March 2025 as a backup to ML-KEM, in case quantum computers someday crack ML-KEM 4. A system that can swap algorithms by configuration survives that kind of change. A system with algorithms hard-coded into it needs a code release for each one.

Four design patterns from OMB

OMB's memorandum sets out patterns for agencies 2. They apply equally to private organizations.

1. Use modern libraries built for agility. OpenSSL 3.x uses a provider architecture, and Java's JCA and JCE let you register different cryptographic providers 2.
2. Put algorithm choice in configuration. The choice of algorithm or hybrid scheme belongs in external configuration files, not compiled code 2.
3. Negotiate in the protocol. Communication protocols should include fields for negotiating cryptographic capabilities 2.
4. Make key management agile. Key management services and hardware security modules must handle both classical and post-quantum keys 2.

Six steps to become agile

Canada's guidance lists six steps 3. They translate directly into a program plan:

1. Create a comprehensive inventory of products that use cryptography. See How to Build a Cryptographic Inventory.
2. Add policies and procedures for cryptography to IT change management.
3. Ask vendors how they support agility and how upgrades work.
4. Develop a transition plan for any non-agile product, including legacy systems.
5. Set procurement policies that prioritize agility.
6. Use standardized, validated algorithms everywhere.

The same guidance says agility relies on configuration that avoids major software or hardware updates, on streamlined firmware and software upgrades, and on keeping interoperability and validations intact 3.

Plan for co-existence

The NCSC expects traditional and post-quantum public-key cryptography to co-exist in your environment for some time. It asks organizations to choose solutions with cryptographic agility and to set clear criteria for deprecating the older algorithms 5. Write that criterion down now: which event, such as a vendor announcement, a standards change, or a date, triggers removal of RSA and elliptic-curve algorithms from each system.

Anti-patterns to remove

These are ArcQubit engineering guidance, not quotations from a standard.

• Hard-coded algorithm names or key sizes. Every one becomes a code change later.
• Fixed-size buffers for keys, ciphertexts, and signatures. Post-quantum objects are larger. The ML-KEM-768 public key in the example below is 1,184 bytes, compared with 32 bytes for X25519.
• Certificate pinning with no rotation plan. A pin that cannot change blocks migration.
• Home-grown wrappers that hide the algorithm. They make inventory and change harder.
• Protocols that cannot negotiate. Prefer designs where both sides agree on an algorithm and downgrade is detected.

A small example in Go

Illustrative code. We compiled and ran it on Go 1.26.7. Sizes below come from that run.

Application code calls one interface. A registry maps a configuration value to an implementation. To change algorithms, change the configuration value, not the calling code.

package main

import (
    "bytes"
    "crypto/ecdh"
    "crypto/mlkem"
    "crypto/rand"
    "fmt"
    "os"
)

// KEM is the only interface application code sees.
type KEM interface {
    Name() string
    Generate() (pub []byte, decap func(ct []byte) ([]byte, error), err error)
    Encapsulate(pub []byte) (ct, secret []byte, err error)
}

type x25519 struct{}

func (x25519) Name() string { return "x25519" }
func (x25519) Generate() ([]byte, func([]byte) ([]byte, error), error) {
    k, err := ecdh.X25519().GenerateKey(rand.Reader)
    if err != nil {
        return nil, nil, err
    }
    return k.PublicKey().Bytes(), func(ct []byte) ([]byte, error) {
        p, err := ecdh.X25519().NewPublicKey(ct)
        if err != nil {
            return nil, err
        }
        return k.ECDH(p)
    }, nil
}
func (x25519) Encapsulate(pub []byte) ([]byte, []byte, error) {
    p, err := ecdh.X25519().NewPublicKey(pub)
    if err != nil {
        return nil, nil, err
    }
    e, err := ecdh.X25519().GenerateKey(rand.Reader)
    if err != nil {
        return nil, nil, err
    }
    s, err := e.ECDH(p)
    return e.PublicKey().Bytes(), s, err
}

type mlkem768 struct{}

func (mlkem768) Name() string { return "mlkem768" }
func (mlkem768) Generate() ([]byte, func([]byte) ([]byte, error), error) {
    dk, err := mlkem.GenerateKey768()
    if err != nil {
        return nil, nil, err
    }
    return dk.EncapsulationKey().Bytes(), dk.Decapsulate, nil
}
func (mlkem768) Encapsulate(pub []byte) ([]byte, []byte, error) {
    ek, err := mlkem.NewEncapsulationKey768(pub)
    if err != nil {
        return nil, nil, err
    }
    secret, ct := ek.Encapsulate()
    return ct, secret, nil
}

var registry = map[string]KEM{"x25519": x25519{}, "mlkem768": mlkem768{}}

func fromConfig(name string) (KEM, error) {
    k, ok := registry[name]
    if !ok {
        return nil, fmt.Errorf("unknown kem %q", name)
    }
    return k, nil
}

func main() {
    name := os.Getenv("KEM_ALG") // stands in for a config file or KMS policy
    if name == "" {
        name = "x25519"
    }
    kem, err := fromConfig(name)
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
    pub, decap, err := kem.Generate()
    if err != nil {
        panic(err)
    }
    ct, s1, err := kem.Encapsulate(pub)
    if err != nil {
        panic(err)
    }
    s2, err := decap(ct)
    if err != nil {
        panic(err)
    }
    fmt.Printf("%s pub=%dB ct=%dB match=%v\n", kem.Name(), len(pub), len(ct), bytes.Equal(s1, s2))
}

Running it with each setting printed:

x25519 pub=32B ct=32B match=true
mlkem768 pub=1184B ct=1088B match=true

The example shows two agility points. The calling code never names an algorithm, and the size difference (32 bytes against 1,184 bytes for the public key) shows why fixed-size buffers fail. It is a teaching sketch, not a production key exchange: use your TLS library's hybrid support for real connections.

How to measure agility

Ask five questions of every system that uses cryptography. Can you change the algorithm through configuration? Can the protocol negotiate? Does key management store post-quantum keys? Do your vendors document an upgrade path? Does your inventory show where the algorithm lives? Systems that fail these tests go on the transition list Canada recommends for non-agile products 3. The Readiness Self-Assessment turns these questions into a score.

What crypto agility means for executives and the board

The rest of this article is ArcQubit guidance, not quotation from a standard.

Crypto agility is a business capability, not a developer preference. It decides how much a forced algorithm change costs you and how long it takes. Your CISO owns the technical program. Your CEO and board own the outcome: whether the organization can respond when a standard, a regulator or a supplier forces a change.

Frame it as a resilience question. NIST's definition centers on preserving security and ongoing operations while algorithms change 1. If your systems cannot change algorithms without a code release, every future change becomes a project with its own budget, outage risk and audit trail.

What it costs to stay rigid

We do not put numbers on this, because the cost depends on your estate. The drivers are clear:

• Supplier dependence. If a vendor hard-codes its algorithms, you wait for the vendor's roadmap. Canada's guidance tells you to ask vendors how they support agility and how upgrades work 3.
• Procurement lead time. Hardware security modules and embedded devices take time to buy and replace. Rigid products turn an algorithm change into a hardware refresh.
• Audit exposure. Regulators expect agencies to plan for migration 2. A system you cannot inventory or change is a finding waiting to happen.
• Repeated rework. Standards keep moving 4. A rigid system pays the full migration cost each time, not once.

Questions to ask your team this week

1. Which of our systems choose an algorithm in configuration, and which hard-code it?
2. Where do we store keys, and can that system hold post-quantum keys 2?
3. Which vendors can tell us, in writing, how their upgrades work 3?
4. Which products have no upgrade path, and what is our transition plan for them 3?
5. Does our change-management process cover cryptography 3?
6. What event triggers removal of RSA and elliptic-curve algorithms from each system 5?
7. Do our procurement rules reward agility 3?

Decisions leadership must make first

Your leadership team makes these calls. Delay on any of them slows every engineering team below it.

1. Name one accountable owner. Pick a single executive for crypto agility and give that person authority over standards and exceptions.
2. Adopt agility as a procurement criterion. Canada lists this as a step 3. Tell your buyers to ask for it in every renewal and new contract.
3. Fund the inventory. You cannot rank systems you have not found. The inventory guide explains how.
4. Accept a transition list. Decide which non-agile systems you will replace, wrap or retire, and who signs off on the risk you keep.

How to brief your board

Keep it to five points:

• We will change algorithms more than once. Standards are still moving 4.
• Agility lowers the cost of each change. It does not replace migration 2, 5.
• One executive owns the program, and we report progress on the systems that pass the five agility tests.
• Every vendor contract now asks how the vendor handles algorithm upgrades 3.
• We need budget for inventory first, then for the systems on the transition list.

Common mistakes

• Treating agility as a one-time project. It is a standing capability. Test it whenever you add a system.
• Wrapping algorithms in a home-grown layer. This hides the algorithm from your inventory and makes change harder.
• Fixing software and forgetting key management. Your key management services and HSMs must hold both key types 2.
• Skipping the removal criterion. Without a written trigger, old algorithms stay forever 5.
• Buying on features alone. A product that cannot upgrade its cryptography adds to your transition list.

Owner and timeline

ArcQubit guidance. Adjust to your organization.

How ArcQubit approaches it

This box describes ArcQubit's own method. Keep it separate from the guidance above.

ArcQubit's Crypto Agility Lifecycle Model ends with continuous crypto agility as its eighth phase: making the ability to swap algorithms a standing capability as standards, infrastructure, and threats keep moving. ArcQubit's QuTrust product covers that phase and builds crypto agility into an organization's existing cyber program.