Why Software Providers Must Act
Software and SaaS providers face two distinct categories of post-quantum risk: risk to their own data and systems, and risk to their customers through the trust relationships they maintain. The second category is unique to software providers and makes code signing migration an especially urgent priority.
A software provider's code signing key is the root of trust for every software update delivered to customers. If that key is ever compromised, whether by a classical breach or a future quantum attack, an adversary could forge software updates that appear to be legitimate. Customers who trust signed updates would install malicious software without detection.
Code Signing: The Most Urgent Priority
Code signing is the mechanism by which software developers attest that a software package was produced by them and has not been modified since signing. Virtually all code signing infrastructure today uses RSA or ECDSA signatures, both of which are vulnerable to Shor's algorithm on a sufficiently large quantum computer.
The harvest-now-decrypt-later analogy for code signing is archive-now-forge-later. An adversary who collects signed software packages today cannot yet forge signatures. But if they develop quantum capability in the future, they can generate new packages with forged signatures that appear to have been signed by the legitimate provider. Migrating code signing to ML-DSA or SLH-DSA eliminates this future forgery risk for packages signed after the migration.
SLH-DSA is often recommended for root code signing certificate authorities because its conservative hash-based security assumptions provide higher confidence for long-lived root keys. ML-DSA is appropriate for leaf code signing certificates, where smaller signatures and faster signing are operationally beneficial.
SaaS TLS and API Security
SaaS platforms protect customer data in transit using TLS. Enabling hybrid TLS (X25519 + ML-KEM-768) on all customer-facing endpoints provides immediate HNDL protection for new traffic. This does not require application changes for most SaaS platforms, only TLS library and server configuration updates.
API authentication using RSA or ECDSA-signed tokens should be migrated to ML-DSA signatures. JSON Web Token (JWT) profiles for post-quantum signatures are being developed in IETF working groups. Until standardized profiles are available, hybrid approaches or migration to symmetric shared secrets can provide interim protection.
Customer data encryption at rest should be reviewed. Symmetric encryption (AES-256) used for data at rest is already post-quantum resistant. However, the key management infrastructure that protects symmetric keys may use RSA or ECDH for key wrapping, which is vulnerable. Key management systems should be included in the cryptographic inventory.
CI/CD and Package Registry Security
Continuous integration and continuous deployment pipelines sign build artifacts, container images, and release packages. These signing operations should be migrated to ML-DSA to prevent future forgery of CI/CD artifacts.
Software repositories and package registries (npm, PyPI, Maven Central, and similar) are high-value targets for supply chain attacks. Post-quantum code signing for packages distributed through public registries protects the integrity of the software supply chain for downstream consumers.
Build environments and signing infrastructure are themselves attack surfaces. Signing keys stored in cloud key management systems, HSMs, or CI/CD secrets must be protected by post-quantum key wrapping before the entire signing chain is secured.
Customer-Facing Implications
SaaS providers should communicate their post-quantum roadmap to customers as part of their security transparency practices. Enterprise customers increasingly require suppliers to provide information about cryptographic security posture as part of vendor risk assessments.
Multi-tenant SaaS platforms must ensure that post-quantum migrations do not create cryptographic inconsistencies between tenants. If some tenants receive ML-KEM-protected connections and others do not, the security posture across the platform is inconsistent and may be difficult to communicate accurately.
Implementation Approach
The migration priority order for software and SaaS providers is: code signing infrastructure first, followed by TLS for customer-facing services, followed by API authentication and internal service-to-service communications.
Code signing migration begins with assessing the current signing infrastructure: where signing keys are stored, what algorithm is used, which CI/CD systems invoke signing, and what the certificate hierarchy looks like. The migration plan must maintain signing continuity for existing releases while introducing post-quantum signing for new releases.
Post-quantum readiness should be incorporated into the software development lifecycle as a standard requirement. New cryptographic library dependencies should be reviewed for post-quantum support before adoption. Security policies should require post-quantum algorithms for new system designs.