OpenSSL 3.0 to 3.5 PQC Migration Worksheet

Moving from an OpenSSL 3.0-era deployment to OpenSSL 3.5 can provide native ML-KEM, ML-DSA, and SLH-DSA implementations, but a package upgrade does not automatically make an application post-quantum secure. The application must use the target provider and APIs, the protocol must negotiate the intended construction, dependencies must interoperate, and production teams need evidence and rollback.

Download the editable OpenSSL 3.0-to-3.5 migration worksheet CSV. Use YES, NO, UNKNOWN, or NOT APPLICABLE in the status column. Replace the prompts with system-specific evidence rather than treating completion as certification.

Lifecycle boundary before technical work

Upstream OpenSSL 3.0 public support ended on September 7, 2026. OpenSSL 3.5 is an LTS release supported upstream through April 8, 2030. Those are upstream dates, not proof that every Linux-distribution package or commercial build follows the same schedule.

Record two lifecycles:

1. the upstream OpenSSL branch;
2. the distribution, appliance, container-base-image, or commercial-provider package you actually deploy.

A vendor-maintained 3.0 package can have a different support contract. Conversely, an application can bundle an unmaintained 3.0 library even when the host operating system is supported. Verify the loaded runtime, not only the package-manager database.

Worksheet status vocabulary

Status	Meaning
YES	Verified with current evidence for this exact environment
NO	Checked and not satisfied; action or exception required
UNKNOWN	Not yet checked or evidence is missing
NOT APPLICABLE	Outside the defined scope, with a recorded reason

“YES” should point to a command output, build manifest, test report, ticket, vendor document, or approved decision. It should not mean “probably.”

A. Inventory the current environment

Check	Status	Evidence to capture
Exact runtime version and build options identified	UNKNOWN	openssl version -a, package build, image digest, compile flags
Loaded library matches the CLI binary	UNKNOWN	Process/library inspection, runtime diagnostics, application startup log
Upstream and package-provider support windows recorded separately	UNKNOWN	OpenSSL lifecycle plus distribution or vendor source
Build and delivery method identified	UNKNOWN	OS package, source build, static link, vendored library, container, appliance
Every linked application and service owner identified	UNKNOWN	Service inventory, package dependency output, build manifests
Current configuration files and environment overrides collected	UNKNOWN	openssl.cnf, include paths, environment variables, application overrides
Current providers and engines identified	UNKNOWN	Provider list, engine list, HSM/KMS integration documentation
Current TLS versions, groups, ciphers, certificates, and keys recorded	UNKNOWN	Config, handshake capture, certificate inventory, key location

Use the cryptographic inventory guide if the estate is not yet mapped. An OpenSSL migration scoped only to one executable can miss reverse proxies, language runtimes, plugins, agents, appliances, and statically linked copies.

B. Define the target rather than “enable PQC”

Requirement	Status	Target and evidence
Cryptographic function identified	UNKNOWN	TLS key establishment, standalone KEM, signing, verification, certificate, code signing, other
Exact target algorithm or construction named	UNKNOWN	For example ML-KEM-768, ML-DSA-65, SLH-DSA variant, or X25519MLKEM768
Standards and protocol status recorded	UNKNOWN	NIST standard, RFC, draft, vendor construction, internal profile
Peer or dependent-system support verified	UNKNOWN	Client, server, CA, HSM, middleware, load balancer, scanner
Hybrid requirement and fallback policy documented	UNKNOWN	Approved groups, ordering, downgrade behavior, exit criteria
Success is measurable	UNKNOWN	Negotiated group, verified signature, key operation, compatibility result

OpenSSL 3.5 implements ML-KEM-512/768/1024, ML-DSA-44/65/87, and SLH-DSA variants in its provider architecture. Those primitive implementations do not mean every protocol, certificate ecosystem, application, or hardware key store can use them.

For TLS, OpenSSL 3.5’s default group list predicts an X25519MLKEM768 key share. A successful upgrade still requires the application to use the new library, the relevant configuration to remain active, and the peer and network path to tolerate the handshake. The RFC 10024 hybrid TLS guide explains standardized group names and interoperability.

C. Check application and API compatibility

Check	Status	Evidence to capture
Application vendor supports OpenSSL 3.5	UNKNOWN	Supported-version matrix or written vendor confirmation
Source builds cleanly with the target headers	UNKNOWN	Build log with deprecation warnings reviewed
Runtime links to the intended 3.5 library	UNKNOWN	Linker/runtime inspection in the deployed artifact
High-level EVP APIs are used where required	UNKNOWN	Code review and integration tests
Deprecated low-level calls are inventoried	UNKNOWN	Static analysis, compiler output, code search
Engine dependencies have a provider migration plan	UNKNOWN	Vendor roadmap, provider module, tested compatibility path
Encoding, decoding, key import/export, and store loaders work	UNKNOWN	Round-trip tests with production-like key material
Language bindings and native extensions support the target	UNKNOWN	Binding version, ABI test, packaging evidence

OpenSSL 3.x releases with the same major version are API- and ABI-compatible under OpenSSL’s versioning policy, but that does not eliminate application risk. New features, provider selection, deprecated APIs, configuration, packaging, and external modules still need testing. Engine-backed workflows have limited forward applicability; OpenSSL encourages engine authors to move to providers.

D. Providers, configuration, and FIPS requirements

Check	Status	Evidence to capture
Required providers load explicitly and in the intended order	UNKNOWN	openssl list -providers, application diagnostics, config review
Default provider remains available when other providers are activated	UNKNOWN	Provider and algorithm-list output
Property queries select the intended implementation	UNKNOWN	fips=yes or other property query plus test evidence
Legacy-provider dependencies are identified	UNKNOWN	Algorithm inventory and provider mapping
FIPS requirement is defined per environment and operation	UNKNOWN	Policy owner, module boundary, required certificate
Installed FIPS module/version has the required validation status	UNKNOWN	CMVP certificate and exact module version
PQ algorithm availability is not confused with FIPS validation	UNKNOWN	Provider output plus current validation record
HSM/KMS/provider module supports the target keys and operations	UNKNOWN	First-party capability documentation and integration test

OpenSSL documentation lists PQ algorithms in default and FIPS-provider implementations, but implementation availability is not the same as a deployed module holding a current FIPS 140 validation covering the required operation. OpenSSL reports that 3.5.4 has been submitted for FIPS 140-3 validation. Verify the exact installed module and current CMVP record instead of inferring compliance from the branch number.

Use the FIPS 140-2 to FIPS 140-3 transition guide to classify Active, Historical and Revoked certificates and to distinguish existing-system exceptions from new-system procurement.

OpenSSL configuration has another operational trap: explicitly activating a non-default provider can require explicitly activating the default provider too. A configuration that works in the CLI may differ from an application using its own library context or property query.

E. Key and certificate handling

Check	Status	Evidence to capture
Existing private keys remain loadable after upgrade	UNKNOWN	Test with copies in staging; never expose production keys
New PQ keys can be generated, stored, backed up, and restored	UNKNOWN	Key lifecycle test and ownership record
Key encodings and application serializers interoperate	UNKNOWN	PKCS#8/public-key round trip and peer test
Certificate or trust-chain dependencies are separately assessed	UNKNOWN	CA/browser/client/HSM support matrix
Rotation, revocation, recovery, and destruction procedures cover new keys	UNKNOWN	Runbook and exercised recovery evidence
Key-size and signature-size impacts are measured	UNKNOWN	Storage, message, certificate, HSM, and transport tests

ML-KEM is a key-encapsulation mechanism. ML-DSA and SLH-DSA are signature algorithms. Enabling hybrid TLS key establishment does not migrate certificate signatures, code signing, document signatures, authentication, or stored-data encryption.

Use the NIST PQC standards guide to keep ML-KEM, ML-DSA, and SLH-DSA functions separate. The PQC algorithm reference records their standardized parameter sets.

F. TLS and interoperability plan

Check	Status	Evidence to capture
Target clients and servers negotiate the intended group	UNKNOWN	Handshake output or packet capture with exact versions
Classical-only peers follow the approved compatibility path	UNKNOWN	Positive and negative interop tests
Middleboxes accept larger ClientHello and handshake messages	UNKNOWN	Tests through production-like firewall, proxy, IDS, and TLS inspection
Group ordering and fallback behavior match policy	UNKNOWN	Server/client configuration and negotiation matrix
Resumption, load balancing, health checks, and monitoring still work	UNKNOWN	End-to-end staging evidence
Performance and message-size baselines are recorded	UNKNOWN	Latency, CPU, memory, bandwidth, connection-rate measurements

Do not copy a benchmark from another environment into the acceptance record. Test the exact build, CPU, compiler, application, protocol settings, and network path. The OpenSSL quantum-safe configuration guide gives configuration examples; this worksheet supplies the surrounding deployment controls.

G. Build a production-like test environment

Check	Status	Evidence to capture
Staging mirrors production library loading and config paths	UNKNOWN	Image/build comparison and startup output
Representative clients, servers, and failure cases are included	UNKNOWN	Test matrix and version inventory
PQ operations are verified directly	UNKNOWN	Algorithm/provider lists plus KEM/sign/verify results
Protocol use is verified independently of primitive availability	UNKNOWN	Negotiation or application-level evidence
Security, load, recovery, and rollback tests pass	UNKNOWN	Test reports with thresholds and owners
Logs expose version, provider, negotiation, and failure signals safely	UNKNOWN	Sample telemetry without secret material

The PQC implementation test guide provides a wider laboratory plan. Keep test artifacts linked to the migration record rather than replacing them with a checkbox.

H. Rollout and rollback

Check	Status	Evidence to capture
Rollout population and canary order defined	UNKNOWN	Hosts, services, users, regions, or traffic percentage
Go/no-go thresholds approved	UNKNOWN	Error rate, latency, interop, security, and business thresholds
Previous package/image/config remains recoverable	UNKNOWN	Immutable artifact, repository reference, retention period
Database, key, or certificate changes are reversible or staged	UNKNOWN	Migration sequence and recovery procedure
Rollback authority and communication path assigned	UNKNOWN	Named role, escalation route, maintenance window
Rollback has been rehearsed under production-like conditions	UNKNOWN	Timed exercise and result
Post-rollout monitoring window and owner defined	UNKNOWN	Dashboard, alert, review date, incident process

A rollback plan is not “downgrade the package.” Library, configuration, keys, certificates, state, and linked applications may change together. Define the known-good bundle and any irreversible step before production rollout.

I. Post-migration verification

Check	Status	Evidence to capture
Production process loads the approved version and providers	UNKNOWN	Runtime evidence from each deployment class
Required PQ capability is actually used	UNKNOWN	Negotiation, encapsulation, sign, or verify evidence
Classical and unsupported paths behave as designed	UNKNOWN	Compatibility and failure test
Logs, metrics, alerts, and inventory show the new state	UNKNOWN	Dashboard and updated CBOM/inventory record
Support and vulnerability processes track the new branch	UNKNOWN	Owner, advisory feed, patch SLA, next review date
Temporary compatibility settings have owners and expiry criteria	UNKNOWN	Exception record and removal milestone

Migration is complete only for the defined system and cryptographic function. OpenSSL 3.5 can be a necessary platform step without completing an organization’s wider PQC migration.

Sources

• OpenSSL 3.5 final release — PQ algorithms, LTS dates, and the 3.0 upstream support boundary.
• OpenSSL migration guide — provider architecture, deprecated APIs, engines, and versioning.
• OpenSSL configuration documentation — provider activation and property configuration.
• OpenSSL default provider — implemented ML-KEM, ML-DSA, and SLH-DSA algorithms.
• OpenSSL ML-KEM documentation — parameter sets and provider implementation.
• OpenSSL ML-DSA documentation — signature parameter sets and provider implementation.
• OpenSSL FIPS-provider status — current validated-module records and 3.5.4 submission status.
• OpenSSL TLS group configuration — default X25519MLKEM768 behavior and interoperability caveat.

Related resources

• Best Post-Quantum Cryptography Libraries
• PQC Library Comparison Matrix
• Post-Quantum Migration Checklist
• PQC Migration Plan Template