Quantum computing is creating a new challenge for cybersecurity. Discover how post-quantum cryptography, crypto agility, and proactive security planning can help protect your business against tomorrow’s threats.
Introduction: The Future of Encryption Is Already a Business Concern
Modern businesses depend on encryption to protect financial transactions, customer information, employee records, government databases, confidential communications, and digital identities. For decades, widely used cryptographic systems such as RSA and Elliptic Curve Cryptography (ECC) have helped secure this information against conventional computing attacks.
However, advances in quantum computing are challenging the long-term security assumptions behind these technologies.
A sufficiently powerful, fault-tolerant quantum computer could use algorithms such as Shor’s algorithm to break widely deployed public-key cryptographic systems that depend on the mathematical difficulty of factoring large integers or solving discrete logarithm problems. This could undermine important parts of today’s secure communications, digital signatures, and identity verification infrastructure.
The immediate concern is not that every encrypted system can already be broken by quantum computers. Such a machine capable of breaking widely deployed cryptography at scale has not been demonstrated. The concern is that organizations may need years to identify vulnerable systems, replace cryptographic components, test compatibility, and complete a secure migration.
Meanwhile, attackers may already be collecting encrypted information in preparation for future decryption.
The solution involves two closely related concepts: Post-Quantum Cryptography (PQC) and Crypto Agility.
PQC introduces cryptographic algorithms designed to resist attacks from both conventional and quantum computers. Crypto agility enables organizations to replace cryptographic algorithms and related components without rebuilding their entire technology infrastructure.
For businesses, software developers, financial institutions, and government agencies, preparing for this transition is becoming an important part of long-term cybersecurity planning.
1. Understanding Post-Quantum Cryptography (PQC)
Post-Quantum Cryptography refers to cryptographic algorithms designed to remain secure against known attacks from both classical computers and sufficiently powerful quantum computers.
Unlike quantum cryptography, which relies on principles of quantum physics, PQC uses mathematical problems that are believed to remain difficult for quantum computers to solve.
The objective is straightforward: protect digital information without requiring organizations to replace all their existing computers with quantum-resistant hardware.
PQC algorithms can be implemented in software, communication protocols, and other systems, although the transition requires careful engineering, compatibility testing, and appropriate security validation.
Why are RSA and ECC vulnerable?
RSA relies on the difficulty of factoring large numbers, while ECC relies on mathematical problems involving elliptic curves and discrete logarithms.
Conventional computers cannot efficiently solve these problems at the sizes used by properly configured modern cryptographic systems. However, a sufficiently capable quantum computer running Shor’s algorithm could solve the corresponding mathematical problems much more efficiently.
This creates a potential risk for technologies that rely on these systems, including:
- Secure connections between websites and users.
- Digital certificates and public-key infrastructure.
- Secure key exchange between applications and servers.
- Digitally signed software and firmware.
- Authentication systems that rely on vulnerable public-key signatures.
- Encrypted communications containing sensitive or long-lived information.
The precise impact depends on how each system uses cryptography. For example, quantum computers do not threaten all encryption algorithms in the same way. Symmetric encryption and cryptographic hashing have different security properties and generally require different mitigation strategies.
The important distinction is that quantum computing threatens particular cryptographic foundations, not every security technology equally.
The NIST standards leading the transition
The US National Institute of Standards and Technology (NIST) published three principal post-quantum cryptography standards in August 2024. These provide organizations with established algorithms for beginning their migration.
The standards are:
1. FIPS 203 — ML-KEM
The Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber, establishes shared secret keys between communicating parties.
It is intended to help protect key establishment against attacks from sufficiently powerful quantum computers.
2. FIPS 204 — ML-DSA
The Module-Lattice-Based Digital Signature Algorithm, derived from CRYSTALS-Dilithium, provides digital signatures that can be used to verify the authenticity and integrity of digital information.
3. FIPS 205 — SLH-DSA
The Stateless Hash-Based Digital Signature Algorithm, derived from SPHINCS+, provides another standardized approach to quantum-resistant digital signatures based on hash functions.
These standards address different cryptographic needs. ML-KEM is used for key establishment, while ML-DSA and SLH-DSA are used for digital signatures.
They are not interchangeable, and adopting them requires selecting the right algorithm for each use case.
2. The Hidden Threat: Harvest Now, Decrypt Later
One of the most important reasons to prepare for post-quantum cryptography today is a threat known as Harvest Now, Decrypt Later (HNDL).
The concept is simple but potentially damaging.
An attacker collects encrypted information today, stores it, and waits for future advances in computing or cryptanalysis that may make it possible to decrypt that information.
The attacker does not necessarily need to read the stolen information immediately for the operation to be worthwhile.
How the attack works
Consider a simplified scenario involving an organization that exchanges sensitive information over an encrypted network.
Stage 1: Harvest
An attacker obtains encrypted traffic or copies encrypted files from a compromised system, exposed storage service, or other accessible source.
Stage 2: Store
The attacker retains the encrypted information, potentially for years, while waiting for cryptographic capabilities to improve.
Stage 3: Decrypt
If future capabilities allow the attacker to recover the necessary cryptographic secrets, some previously protected information may become readable.
The attack’s success depends on several factors, including the encryption methods used, how the data was protected, the attacker’s access, and the availability of a suitable future decryption capability.
Nevertheless, the possibility changes how organizations should evaluate the lifespan of sensitive information.
Why stolen encrypted data can remain valuable
Not all information loses its value quickly.
Some data must remain confidential for years or decades. Examples include:
- Government records containing sensitive personal information.
- Financial records and confidential commercial agreements.
- Healthcare information and medical histories.
- Intellectual property, proprietary designs, and research findings.
- Personal identification information and identity documents.
- Confidential business strategies and long-term investment plans.
- Sensitive communications involving public institutions.
If information stolen today remains valuable when quantum computing advances, encrypting it with a quantum-vulnerable public-key system may not provide adequate long-term protection.
This is especially important for organizations that store information with long confidentiality requirements.
An attacker does not have to defeat your encryption today if the information will still be valuable when that encryption becomes vulnerable.
What businesses should do now
Organizations should identify information that would cause serious harm if exposed in five, ten, or twenty years.
They should then investigate how that information is encrypted, how encryption keys are established and managed, and whether vulnerable public-key algorithms are involved.
Prioritization should consider both the sensitivity of the information and the time it must remain confidential.
A practical approach is to prioritize information with a long confidentiality lifespan, systems with significant exposure, and cryptographic dependencies that will be difficult to replace.
NIST identifies harvest-now-decrypt-later attacks as a key reason organizations should begin preparing for the post-quantum transition before cryptographically relevant quantum computers become available.
3. Crypto Agility: Building Systems That Can Adapt
Preparing for quantum computing requires more than selecting a new encryption algorithm. Organizations must also ensure that their systems can adapt when cryptographic standards, security requirements, or threat conditions change.
This is where cryptographic agility, or crypto agility, becomes essential.
Crypto agility is the ability to replace or adapt cryptographic algorithms, protocols, and implementations while maintaining the security and operational continuity of applications and infrastructure.
In practical terms, a cryptographically agile system does not depend on a single encryption algorithm being secure forever. Instead, it is designed to accommodate changes without requiring a complete system redesign.
NIST’s guidance on crypto agility emphasizes the need to make cryptographic transitions manageable across applications, software, hardware, firmware, protocols, and infrastructure.
The problem with hardcoded cryptography
Consider a business application built with RSA encryption directly embedded throughout its codebase.
The developer uses RSA for key exchange, stores assumptions about RSA key sizes in several modules, and builds authentication logic around RSA-based digital signatures.
Initially, the application works correctly.
However, if the organization later needs to transition to post-quantum cryptography, the development team may have to identify and modify numerous interconnected components.
The challenges could include:
- Locating every use of the vulnerable algorithm.
- Updating libraries and dependencies.
- Reworking authentication and key-exchange processes.
- Maintaining compatibility with older clients and external services.
- Migrating existing encrypted data and cryptographic keys where necessary.
- Testing performance, security, and interoperability.
- Coordinating updates across multiple environments.
The problem is not simply that RSA may eventually become unsuitable for particular security purposes. The problem is that the software was designed around an assumption that its cryptographic foundations would not need to change.
A lack of crypto agility turns an algorithm migration into a costly software redevelopment project.
The solution: Separate cryptography from business logic
Developers should avoid scattering cryptographic decisions throughout application code.
Instead, they should introduce a dedicated cryptographic abstraction layer that centralizes algorithm selection, key management, and cryptographic operations behind well-defined interfaces.
For example, imagine a business application that encrypts customer documents.
A poorly structured implementation might call a specific RSA library directly from several different application modules.
An improved implementation would use a centralized encryption service.
The application would request an encryption operation without needing to know every detail of the underlying cryptographic implementation.
Conceptually, the architecture could look like this:
Application Business Logic → Cryptographic Service Interface → Approved Cryptographic Provider → Selected Algorithm
The cryptographic service manages the approved algorithms and their configurations. The business application interacts with the service through a stable interface.
When the organization needs to adopt a different cryptographic implementation, developers can update the provider or service configuration rather than rewriting every business process.
This approach does not eliminate migration work. Cryptographic transitions may still require changes to data formats, communication protocols, key management, certificates, and integrations.
However, it can significantly reduce unnecessary coupling between business functionality and specific cryptographic algorithms.
Example: Designing for future algorithm replacement
Consider a simplified Python architecture:
from abc import ABC, abstractmethod
class EncryptionProvider(ABC):
@abstractmethod
def encrypt(self, plaintext: bytes) -> bytes:
pass
@abstractmethod
def decrypt(self, ciphertext: bytes) -> bytes:
pass
class DocumentService:
def __init__(self, encryption_provider):
self.encryption_provider = encryption_provider
def protect_document(self, document: bytes) -> bytes:
return self.encryption_provider.encrypt(document)
def retrieve_document(self, ciphertext: bytes) -> bytes:
return self.encryption_provider.decrypt(ciphertext)
This example illustrates an architectural principle rather than a complete encryption implementation.
The document service depends on an interface instead of a specific encryption library.
An approved cryptographic provider can be supplied through dependency injection, allowing the application to separate document-processing functionality from the underlying encryption implementation.
Important: This code does not implement encryption itself. A production implementation must use a vetted cryptographic library, authenticated encryption, appropriate key management, secure error handling, and a documented format for identifying cryptographic versions.
It must also distinguish between symmetric data encryption and public-key operations such as key establishment and digital signatures.
A further design consideration is that not all algorithms can be swapped transparently. PQC adoption may require changes to key sizes, signature sizes, protocol messages, certificates, and storage formats.
Crypto agility makes these changes more manageable; it does not make them unnecessary.
4. Practical Steps for Software Developers to Prepare for PQC
Software developers have a significant role to play in the post-quantum transition because architectural decisions made today can determine how easily applications adapt to tomorrow’s security requirements.
The following practices can help development teams build systems that are easier to migrate.
Step 1: Create a cryptographic inventory
Before replacing algorithms, determine where cryptography is being used.
Review the application codebase, third-party libraries, APIs, communication protocols, databases, authentication systems, certificates, and infrastructure configurations.
Identify:
- Public-key encryption and key-establishment mechanisms.
- RSA and ECC usage.
- Digital-signature algorithms.
- Symmetric encryption algorithms.
- Hash functions and message authentication mechanisms.
- Cryptographic libraries and their versions.
- Certificate authorities and public-key infrastructure dependencies.
- External services that control their own cryptographic implementations.
The inventory should identify not only the algorithm but also its purpose, location, owner, dependencies, and migration difficulty.
For large organizations, automated discovery tools can help identify cryptographic usage across software repositories and infrastructure.
Step 2: Introduce a cryptographic abstraction layer
Avoid hardcoding algorithm choices throughout application code.
Create centralized services for relevant cryptographic operations, including encryption, key establishment, digital signatures, and verification.
Keep the interfaces clear and limit the number of components that directly access cryptographic libraries.
For example, an application may use separate interfaces for:
- Data encryption and decryption.
- Public-key operations and key establishment.
- Digital signing and signature verification.
- Key generation, storage, rotation, and retirement.
These interfaces should reflect the different security purposes of each operation.
A single generic interface that treats all cryptographic algorithms as interchangeable can introduce design errors. A well-designed abstraction preserves the distinctions between different cryptographic functions.
Step 3: Use maintained cryptographic libraries
Do not attempt to invent proprietary encryption algorithms or implement complex cryptographic primitives from scratch.
Use maintained libraries and platform components that support the required standards and security configurations.
Before adopting a PQC implementation, verify its maturity, maintenance status, interoperability, performance, and suitability for the intended environment.
Where compliance or assurance requirements apply, confirm whether the relevant cryptographic implementation and module have the required validation.
The use of a standardized algorithm does not automatically mean that every implementation of that algorithm is secure or appropriately validated.
Step 4: Design for algorithm versioning
Cryptographic agility requires systems to understand which cryptographic configuration was used to protect a particular piece of data.
For example, an encrypted document format might contain metadata identifying:
- The format version.
- The encryption scheme.
- The key identifier.
- The nonce or initialization vector, where applicable.
- Any required algorithm parameters.
- The authentication tag, where applicable.
This metadata must be handled safely. It should not allow an attacker to force the application to select a weaker algorithm or bypass authentication checks.
Algorithm selection should follow an explicit security policy rather than blindly trusting information supplied by an untrusted message.
When cryptographic formats change, applications may need to retain support for older formats temporarily while securely migrating existing records.
Step 5: Prepare for hybrid cryptographic deployments
During the transition, some systems may need to support both conventional and post-quantum cryptography.
Hybrid approaches can combine a conventional key-establishment mechanism with a post-quantum mechanism, provided the combination follows an appropriate, vetted protocol design.
The intention is to provide protection against different classes of cryptographic threats during the transition.
However, hybrid cryptography must be implemented correctly. Simply combining two algorithms does not automatically create a secure system.
Developers should use supported protocol implementations and follow applicable standards rather than inventing their own hybrid key-exchange constructions.
Step 6: Test performance and compatibility
Post-quantum algorithms can have different computational and communication characteristics from their predecessors.
For example, key sizes, signature sizes, and protocol message sizes may change. These differences can affect systems with limited bandwidth, memory, processing capacity, or strict latency requirements.
Testing should cover:
- Application performance and response times.
- Memory and processor consumption.
- Network message sizes.
- Mobile and low-powered devices.
- API compatibility.
- Authentication and signature verification.
- Backup and recovery processes.
- Interoperability with external services.
- Key rotation and cryptographic migration procedures.
Performance testing is especially important for mobile applications, connected devices, and systems operating over unreliable or bandwidth-constrained networks.
5. Protecting Digital Signatures, Certificates, and Software Updates
Encryption is only one part of the post-quantum transition.
Digital signatures also require attention because they help establish trust in software, communications, certificates, and digital transactions.
If a vulnerable signature scheme can be forged by a sufficiently powerful quantum attacker, the consequences could extend beyond the confidentiality of encrypted information.
Potential risks include fraudulent software updates, compromised authentication processes, forged digital documents, and attacks against trust relationships.
Why digital signatures matter
Digital signatures help verify that information was signed by the holder of a particular private key and has not been altered since signing.
They are used in many environments, including:
- Software distribution and update systems.
- Digital certificates.
- Electronic document signing.
- Application authentication.
- Firmware verification.
- Secure development and deployment pipelines.
NIST’s FIPS 204 and FIPS 205 standards provide post-quantum digital-signature options for appropriate applications.
Organizations should evaluate where conventional public-key signatures are used and determine how those systems can transition to approved alternatives.
This is particularly important for software developers who distribute applications, plugins, firmware, or other digital products that may need to remain verifiable for many years.
The long lifecycle of trust
Consider a software product signed today and distributed to thousands of customers.
If its signing infrastructure depends on a cryptographic scheme that becomes vulnerable in the future, the organization may need to consider how historical signatures are validated, how new releases are signed, and how customers distinguish authentic updates from malicious ones.
A migration plan should therefore address more than the application code itself.
It should include signing keys, certificate infrastructure, build systems, update mechanisms, and the processes used to verify software authenticity.
Post-quantum readiness is a software supply-chain issue as much as it is an encryption issue.
6. A Post-Quantum Readiness Roadmap for Businesses
Organizations do not need to replace every cryptographic component simultaneously.
A structured migration allows them to prioritize their most significant risks while maintaining business continuity.
The following roadmap provides a practical starting point.
| Phase | Recommended action | Intended outcome |
| 1. Assess | Inventory cryptographic algorithms, libraries, certificates, and dependencies. | Establish visibility into existing cryptographic exposure. |
| 2. Prioritize | Identify sensitive data, long confidentiality requirements, and high-risk systems. | Determine which systems require attention first. |
| 3. Plan | Develop a migration strategy aligned with relevant standards and business requirements. | Establish ownership, priorities, timelines, and resources. |
| 4. Architect | Introduce cryptographic abstraction, algorithm versioning, and appropriate key-management practices. | Make future cryptographic changes easier to implement. |
| 5. Pilot | Test supported PQC implementations and hybrid approaches where appropriate. | Validate compatibility, performance, and operational readiness. |
| 6. Migrate | Update vulnerable cryptographic components in a controlled sequence. | Reduce exposure while maintaining service availability. |
| 7. Verify | Test security, interoperability, recovery, and migration completeness. | Confirm that the new configuration works as intended. |
| 8. Maintain | Monitor standards, dependencies, and cryptographic risks continuously. | Keep the organization prepared for future changes. |
The migration should be treated as an ongoing security programme rather than a one-time software upgrade.
Organizations should also involve their technology vendors, cloud providers, payment processors, certificate providers, and other critical service partners.
A business cannot complete its transition independently if important cryptographic components are controlled by third parties.
NIST’s post-quantum migration resources emphasize cryptographic visibility, risk management, interoperability, and the need to plan for transitions across interconnected systems.
7. What This Means for Businesses in Ghana and Across Africa
For businesses, public institutions, financial organizations, and technology providers in Ghana and across Africa, post-quantum cryptography should be considered part of long-term digital infrastructure planning.
Organizations increasingly rely on cloud platforms, electronic payment systems, digital identity services, online government portals, and interconnected business applications.
These systems often depend on cryptographic technologies supplied by external vendors or embedded in software libraries.
A future cryptographic transition could therefore affect multiple systems simultaneously.
Financial services and digital payments
Financial institutions and businesses processing electronic payments should understand which parts of their systems rely on public-key cryptography and how their providers intend to support post-quantum migration.
This includes reviewing dependencies involving secure connections, authentication, digital certificates, transaction-signing systems, and other relevant infrastructure.
Organizations should coordinate with their payment and banking providers rather than attempting to replace cryptographic components within regulated payment systems independently.
Government and public-sector information systems
Public institutions often maintain records that must remain confidential or trustworthy for extended periods.
Examples include personal identification records, administrative databases, procurement documents, financial records, and sensitive correspondence.
Institutions should assess which information requires long-term confidentiality and identify the cryptographic technologies protecting it.
They should also consider the long-term integrity and authenticity of digitally signed records.
Software developers and technology companies
Developers building business management systems, payroll platforms, customer management applications, church management systems, and government information systems can make an important contribution by designing for cryptographic flexibility from the beginning.
New applications should avoid unnecessary dependence on a single cryptographic implementation.
Development teams should also maintain an inventory of third-party dependencies and establish procedures for updating cryptographic libraries when required.
For smaller technology companies, including startups and local software providers, the first step is not necessarily to implement PQC immediately in every application.
It is to understand existing dependencies, follow developments in supported standards, choose maintainable architectures, and prepare a realistic migration plan.
The organizations that prepare early will be better positioned to adapt without unnecessary disruption when cryptographic requirements change.
8. Common Mistakes to Avoid
As organizations begin planning for post-quantum security, several mistakes can undermine their efforts.
Mistake 1: Assuming quantum attacks are only a future problem.
Even if a cryptographically relevant quantum computer is not currently available, information stolen today could remain valuable in the future.
Mistake 2: Replacing RSA with a different algorithm without reviewing the architecture.
A direct substitution may not address dependencies in certificates, protocols, key management, and external integrations.
Mistake 3: Developing custom cryptographic algorithms.
Proprietary cryptography can introduce vulnerabilities that are difficult to detect. Use established standards and appropriately maintained implementations.
Mistake 4: Ignoring third-party dependencies.
Applications may inherit cryptographic weaknesses from frameworks, plugins, libraries, APIs, or infrastructure providers.
Mistake 5: Assuming every encryption algorithm must be replaced.
PQC migration requires distinguishing between vulnerable public-key operations and other cryptographic mechanisms. Different components require different mitigation strategies.
Mistake 6: Treating crypto agility as an algorithm-selection setting alone.
True agility also requires operational procedures, secure key management, compatible data formats, testing, documentation, and coordinated deployment.
Mistake 7: Waiting until a deadline is announced.
Large migrations can require substantial coordination. Early discovery and planning reduce the risk of rushed changes, unexpected costs, and operational disruption.
Conclusion: Build for Cryptographic Change, Not Just Today’s Threats
Quantum computing presents a significant long-term challenge to widely deployed public-key cryptography. Although the timing of a cryptographically relevant quantum computer remains uncertain, the possibility of harvest-now-decrypt-later attacks makes early preparation important for organizations protecting sensitive information.
Post-quantum cryptography provides standardized approaches to addressing this challenge. Crypto agility provides the architectural and operational foundation for adopting those approaches without unnecessarily disrupting existing systems.
For software developers, this means separating cryptographic operations from business logic, using maintained libraries, managing cryptographic versions carefully, and preparing applications for future algorithm changes.
For business leaders, it means understanding the information they must protect, assessing their technology dependencies, engaging vendors, and establishing a realistic migration strategy.
The objective is not to predict the exact date quantum computing will change cybersecurity. It is to ensure that when cryptographic requirements change, your organization can respond securely and efficiently.
The future of cybersecurity will not belong only to organizations with the strongest encryption. It will also belong to organizations that can adapt their security before their existing protections become inadequate.
How Sikaba Systems Can Help
At Sikaba Systems, we recognize that digital security must evolve alongside the technologies businesses depend on.
We support organizations through the development of business management systems, custom web applications, reporting solutions, and digital infrastructure designed around practical business needs.
As cybersecurity requirements evolve, organizations should also review the security architecture of their existing applications, their software dependencies, and the processes they use to protect sensitive information.
Whether your organization is planning a new digital platform or reviewing an existing system, building with maintainability, security, and future adaptability in mind is an important step toward long-term resilience.
Prepare today. Adapt tomorrow. Protect your digital future.