Transitioning to Quantum-Safe Communication: Adding Q-safe Preference to OpenSSL TLSv1.3

Introduction

For many years, digital security has relied on cryptography built around math problems that are very difficult for regular computers to solve. RSA and elliptic-curve cryptography have formed the foundation of internet security, safeguarding things like banking transactions and software updates.

Quantum computing changes everything. If quantum computers become powerful enough, they could quickly break today’s common encryption, putting sensitive data at risk that was thought to be safe for years. An even bigger worry is ‘harvest now, decrypt later,’ where attackers gather encrypted data now and wait to decrypt it when quantum machines are ready.

As a result, organizations are reviewing their entire cryptography setup and asking if they are prepared. Can they switch to new algorithms without major changes every time standards shift? This is where quantum-safe readiness and crypto-agility matter, not just using new algorithms, but managing and updating cryptography across all systems with confidence.

The Role of TLS 1.3 in Secure Communications

TLS 1.3 is the main protocol that protects sensitive data as it moves across the internet. When you see a lock icon in your browser or a secure API call, TLS is working behind the scenes. TLS 1.3 is faster than older versions and uses stronger default settings, making secure connections simpler to set up.

Currently, TLS 1.3 mostly uses traditional key exchange and signature algorithms, so it still depends on cryptography that quantum computers could eventually break. To protect against future threats, TLS should be able to prefer quantum-safe algorithms during negotiation. Without this, even systems that support quantum-safe options might never use them in practice.

Having a clear and consistent way to say ‘use quantum-safe first, and only fall back if needed’ is important for making real-world deployments practical.

Introducing CBOM Secure

CBOM Secure is our tool for tracking and managing cryptographic assets. It helps organizations see exactly how cryptography is used in their software and infrastructure. Instead of guessing which algorithms are in use or hoping updates worked, CBOM Secure creates a Crypto Bill of Materials (CBOM) that lists all the keys, certificates, and algorithms in your systems.

As organizations move toward quantum-safe security, CBOM Secure lets teams check if their TLS setups are really using quantum-safe preferences, see where old algorithms are still present, and sign CBOM reports for audits. Rather than treating crypto upgrades as a one-time job, our tool helps you keep an ongoing view of your system’s cryptography. When you switch to PQC in OpenSSL or other places, you can prove, track, and trust the change.

Post-Quantum Cryptography and Standards

Understanding Quantum Threats

Worries about quantum computing are not just hype. There is solid math behind them. Security experts are especially concerned about Shor’s algorithm, which lets quantum computers factor large numbers and solve discrete logarithms much faster than regular computers. These two problems are the basis for RSA and elliptic-curve cryptography.

In short:

• RSA stays secure because factoring a giant number takes a ridiculous amount of time today.
• ECC stays secure because solving a discrete logarithm on a normal computer would take far too long to be practical.

But a powerful quantum computer using Shor’s algorithm could break both types of encryption in hours or even minutes. This means data protected by today’s encryption could be exposed in the future.

When people talk about systems being “quantum-safe,” they mean using key exchange and signature algorithms that cannot be broken by quantum machines. These typically include new PQC schemes based on math problems like lattices, codes, or hash-based signatures. In TLS specifically, “quantum-safe” applies to two things:

• Key exchange: ensuring session keys cannot be recovered later
• Digital signatures: proving identity in a way a quantum machine can’t forge

A system is only quantum-safe if it covers both key exchange and digital signatures.

Standards and Mandates

When cryptography changes, standards organizations must clearly define what is allowed, required, or recommended. Without this, no one updates their systems. This is happening now with quantum-safe adoption.

NSA CNSA 2.0 (Commercial National Security Algorithm Suite)

CNSA 2.0 is the U.S. government’s guidance for protecting national security systems. A main point is that agencies and vendors should prefer quantum-safe algorithms in protocols like TLS, not just treat them as optional. This means the negotiation process should choose PQC first when possible, not just support it in theory.

IBM Research has been actively contributing to this shift, including OpenSSL enhancements that allow TLS 1.3 to explicitly prefer a quantum-safe key share. That practical example shows real-world engineering that aligns with CNSA goals.

NIST PQC Standardization

Meanwhile, the National Institute of Standards and Technology (NIST) has been running a long-running global competition to select quantum-safe algorithms for everyday use. This effort produced the first set of finalized selections:

• Kyber for key exchange (branded ML-KEM)
• Dilithium, Falcon, and SPHINCS+ for signatures

Standardized versions of these algorithms are expected to appear in many places, including TLS libraries, browsers, firmware updates, and even small IoT devices. But adoption will take time. Organizations need tools to help them test, verify, and track where and how these new algorithms are used.

At this point, moving to quantum-safe security is less about the cryptography itself and more about operations and visibility. This is where tools like our CBOM Secure are designed to help, as discussed later in the blog.

OpenSSL TLS 1.3 and Algorithm Negotiation

How TLS 1.3 Chooses Cryptographic Algorithms

When a browser, client application, or service wants to establish a secure connection, TLS 1.3 starts with a message called ClientHello. In that message, the client lists the algorithms it supports, ciphersuites, signature schemes, and, most importantly for this discussion, key shares. Key shares define what key-exchange options the client can use to create a shared secret with the server.

The server replies with ServerHello, which selects one option from that list and continues the handshake. Whatever the server picks becomes the basis for the session keys that protect the connection.

TLS 1.3 made a major improvement by reducing round-trips and simplifying the handshake. However, the way algorithms are chosen is still simple: the server selects the first option from the client’s list that both sides support.

That sounds harmless, but it means:

• The order in which the client sends key shares matters
• The server’s internal support list also matters
• TLS will not automatically “prefer” anything unless the logic is specifically built to do so

In traditional setups, this approach works because all key-exchange options are types of elliptic-curve or finite-field algorithms. But with quantum-safe options like ML-KEM (Kyber) now available, the order matters more. Without a preference rule, a system that supports PQC might still use classical algorithms just because of the order.

Limitations in the Current OpenSSL Negotiation

OpenSSL powers a large share of TLS deployments worldwide, either directly in applications or through tools like nginx, Apache, HAProxy, mail servers, VPNs, and SDKs. Adding quantum-safe algorithms to OpenSSL is important, but support alone does not fix the operational challenges.

Today, OpenSSL’s configuration options allow you to:

• Enable or disable specific key-exchange groups
• Set order lists for supported groups
• Build OpenSSL with PQC patches or hybrid modes

However, these controls stop short of offering a clear, enforceable preference rule like:

“Use quantum-safe first, only fall back if the client cannot handle it.”

Instead, TLS behavior depends heavily on:

• The order key shares are listed by the client
• The server’s compiled-in order, which may not reflect the actual policy
• Hidden defaults tied to OpenSSL builds, not real-world operational policy

This means an organization could:

• Enable Kyber (ML-KEM) in OpenSSL
• Configure PQC ciphersuites
• And still never actually see PQC used on live TLS traffic

This is because nothing in the negotiation process enforces a preference. It is more like passive support PQC is only used if both sides happen to choose it.

Passive support is not enough for a quantum-safe transition. Enterprises, auditors, and compliance teams need to prove that PQC is actually being used, not just hope it happens. This limitation is why quantum-safe negotiation needs new engineering work on top of OpenSSL.

Where CBOM Secure Fits In

Automating CBOM Generation for TLS Stacks

Adding quantum-safe features to OpenSSL is only part of the solution. The other part is knowing where these features are actually in use. Most organizations cannot answer basic questions such as:

• Which servers are still using RSA only?
• Which OpenSSL builds include PQC patches?
• Where do TLS libraries differ across environments?

Our CBOM Secure helps by automatically creating a Crypto Bill of Materials (CBOM), which works like a detailed inventory of cryptographic components inside your stack. It can inspect systems, libraries, containers, and packaged binaries to identify:

• The OpenSSL version in use
• Supported TLS groups and key-exchange capabilities
• Whether PQC algorithms are compiled in
• Whether PQC is enabled or simply present

Instead of relying on spreadsheets or guesswork, our tool provides a structured, machine-readable output in JSON or signed reports that show the real cryptographic state of your TLS infrastructure.

This way, you do not have to wait for problems to discover what cryptography is running in production.

Verifying Quantum-Safe Algorithm Support

One of the biggest traps in this field is assuming that “support = usage.” A server might have Kyber compiled in, but never negotiate it for any real connection.

Our CBOM Secure solves this problem by checking configuration and behaviour, not just software presence. It can:

• Scan OpenSSL builds to detect whether PQC key-share groups are enabled
• Verify config files and environment variables that affect TLS negotiation
• Flag deployments where quantum-safe settings exist but are not applied
• Tell you exactly which systems are capable of using PQC and which ones are still classical only

For large organizations, this brings immediate clarity. Instead of making broad statements like ‘we are preparing for PQC,’ teams get a clear yes or no answer for each part of their environment.

This also helps with audits. When you need to ‘prove readiness,’ our tool provides a signed report showing that your TLS stack matches your policy.

Tracking Hybrid and Legacy Algorithms

Quantum-safe rollout is not a single switch. It is a staged journey where production may include a mix of:

• Fully quantum-safe algorithms
• Hybrid algorithms (classical + PQC combined)
• Legacy RSA/ECC is still active for compatibility

Our CBOM Secure tracks this state clearly instead of lumping everything together. It can tell you:

• Which systems negotiated pure PQC sessions
• Which ones negotiated hybrid sessions (for example: ML-KEM + X25519)
• Which ones stayed on legacy only

This insight helps teams make smart decisions. For example:

• If hybrid is still widely used, clients may not support PQC yet
• If legacy remains dominant, migration planning is not complete

Our CBOM Secure turns these points into measurable checkpoints instead of assumptions. You gain visibility into progress and can report it in a way that leadership, security, and engineering teams all understand.

Challenges and Best Practices

Common Integration Pitfalls

Switching to quantum-safe algorithms in TLS sounds simple in theory: turn on ML-KEM, adjust configurations, and you are done. But in real infrastructure, several issues often appear:

• TLS proxies silently drop PQC extensions. Some middleboxes strip unknown key-share values, causing clients to fall back to classical without warning.
• Build variations across environments. A server in staging might use a PQC-enabled OpenSSL build, while production unknowingly runs an older version.
• Hybrid confusion. Development teams turn on hybrid ciphersuites but assume this means pure PQC is already in use.
• Lack of visibility into failures. When PQC negotiation fails, many deployments do not log anything, so teams assume it worked.

The biggest trap is thinking PQC is ‘enabled’ when, in reality, nothing has actually changed in the network traffic.

Best Practices for Tooling and Maintenance

Getting ready for quantum-safe TLS means treating cryptography like any other software component: it should be versioned, tested, and checked regularly. Here are a few practices to help manage this:

• Version pinning: Make sure the OpenSSL builds used in production are pinned and tracked. Do not assume OS package repositories always include the same feature set.
• Integration tests: Add end-to-end TLS handshake tests into CI pipelines. Check actual ClientHello/ServerHello outputs to confirm PQC is negotiated.
• Automation: Use automated tools to scan builds and environments instead of relying on manual checks or documentation.
• Signed artifacts: Produce signed CBOM-based reports so audits and security teams can prove compliance without digging through systems manually.
• Rolling changes: Introduce PQC by targeting a subset of services, first measure results, then expand.

In short, treat PQC support as something to maintain over time, not just a one-time configuration change.

Operational Readiness and Monitoring

Enabling PQC support is only useful if you can prove it is actually happening in production. That requires operational checks, not just deployment-time checks.

Teams should consider:

• TLS handshake telemetry: Collect real connection data and track which key-exchange groups are negotiated.
• Alerting thresholds: Trigger alerts if PQC usage unexpectedly drops, which could signal regressions or configuration drift.
• CBOM-based scheduled scans: Automatically regenerate crypto inventories weekly or monthly to spot changes over time.
• Comparison across tiers: Development, staging, and production should show similar cryptographic properties. If they differ, find gaps.

Operational readiness means knowing the answer to questions like:

• Are we actually using PQC today?
• If not, what stopped it?
• Who needs to fix it?

With monitoring and reporting, PQC usage becomes measurable and what you can measure, you can improve.

Future Directions

Evolving Standards and Algorithm Suites

The cryptography field is always changing. NIST has finalized its first set of post-quantum algorithms, but more updates are expected, including parameter changes, new profiles for lightweight devices, and improvements based on research or real-world feedback.

Upcoming shifts may influence:

• Which Kyber/ML-KEM parameter sets become the “default” for public internet traffic
• Whether new signature schemes replace Dilithium in certain niches
• Hybrid requirements are lasting longer than expected, especially in sectors with slow compliance cycles
• Profiles for IOT, mobile, and constrained devices requiring slimmer key sizes or trimmed variants

Organizations that hard-code their assumptions now may face problems later. The goal should be crypto-agility, so systems can change algorithms and settings without breaking applications or causing downtime. In the next few years, groups like NIST, IETF, and NSA are expected to release clearer deployment profiles, handshake guidance, and PQC-focused TLS policy frameworks.

Extending our CBOM Secure for Broader Crypto-Agility

Right now, our CBOM Secure tool focuses on visibility, showing what cryptography is actually present in an environment. The next step is to help organizations take action based on this information.

Planned roadmap directions include:

• Automated remediation pipelines: When our CBOM Secure detects a system missing PQC support, it could trigger enforcement workflows such as flagging CI pipelines, opening tickets, or deploying patched binaries.
• Cloud-first support: Native integrations with AWS ACM, Azure Key Vault, and Google Cloud KMS to inventory cryptography in hosted services since many TLS endpoints today terminate in the cloud, not on-prem.
• Runtime enforcement: Optional mode where PQC preference policies are pushed directly into services, ensuring that negotiation rules cannot drift silently over time.
• Developer feedback loops: Exposing warnings inside build systems so engineers discover crypto configuration mistakes at commit time rather than after deployment.

The long-term goal is simple: make quantum-safe readiness automatic, so it happens as part of regular software releases, not as a big annual project.

Conclusion

Quantum computing is not just a future theory; it is already pushing organizations to rethink how their certificates, keys, and TLS stacks will stand up to new decryption threats. Waiting until deadlines or last-minute vendor changes is risky. Teams that act now have more control, better planning, and smoother transitions instead of rushed fixes.

Our Encryption Consulting CBOM Secure tool plays a key role in helping organizations prepare. Instead of dealing with spreadsheets, manual OpenSSL outputs, or scattered configuration files, our CBOM tool gives a clear view of crypto usage across environments. It shows which algorithms are in use, what needs to change for post-quantum security, and whether systems meet security goals. For organizations getting ready for board meetings, architecture choices, or compliance planning, our tool provides clarity and speed.

Our CBOM Secure is more than just a reporting tool; it also speeds up the process. It automates crypto inventories, checks TLS configurations, validates algorithms, and aligns policies, so teams can move from discovery to action without guessing. In future releases, Encryption Consulting plans to add automated fixes, cloud-native integrations, and policy enforcement to keep configurations in line with security standards at all times.

Now is a great time to get started: test PQC in a staging environment, map your current crypto usage, and begin creating internal policies. If your organization wants to pilot quantum-safe projects, give feedback, or help shape new features, we at Encryption Consulting encourage you to reach out. The earlier the teams start, the easier the long-term work will be.

If your organization needs support, structured assessments, or a guided approach, Encryption Consulting is ready to help with workshops, advice, and deployment assistance using our CBOM Secure. Contacting us today lets you move into the transition with confidence, instead of waiting until you are forced to change.