Post-quantum encryption (PQE), more broadly called post-quantum cryptography (PQC), uses algorithms designed to resist attacks from conventional computers and future quantum computers. It runs on conventional hardware and protects the mechanisms used to establish encryption keys and authenticate identities and data.

“Q-day” describes the point at which a quantum computer could break widely used public-key cryptography. Some expert assessments suggest this could occur as early as 2028, while others anticipate a longer timeline in the next decade. Advances in quantum hardware, error correction, and algorithms make a precise date difficult to predict. Preparation needs to begin now because migrations take years and information captured today may need to remain confidential for decades.

InterSystems is preparing our products and services that leverage the InterSystems IRIS® data platform for this transition. This document explains what the current state of InterSystems products is today, what is planned, and how organizations can prepare. The technical examples describe InterSystems IRIS platform capabilities; availability in individual products and services depends on their release, deployment, and supporting components.

Governments are encouraging organizations to prepare for the transition to post-quantum cryptography. The United States, Singapore, and the European Union have all published migration guidance and milestones. The programs below are ordered by their earliest milestone; their scope and obligations differ.

Jurisdiction and scope	Published milestone
United States Federal systems excluding national security systems	October 22, 2026: agency migration plans were due under OMB M-26-15. Subsequent milestones prioritize key establishment in 2028–2030 and signatures in 2031, with migration continuing through 2035.
European Union Coordinated roadmap for Member States	End of 2026: begin the transition. The roadmap recommends migrating high-risk uses by the end of 2030 and as many systems as practically feasible by 2035. National and sectoral measures determine organizational obligations.
United States National Security Systems	January 1, 2027: new NSS acquisitions must be CNSA 2.0 compliant unless otherwise noted in NSA guidance. This is an acquisition requirement, distinct from the federal migration-plan deadline.
Singapore Critical Information Infrastructure owners	March 31, 2027: submit migration plans. New procurement and implementation must be quantum-safe or quantum-safe-ready from January 1, 2028; CII migration is to be completed by December 31, 2031.

Organizations should distinguish planning deadlines from deployment deadlines. Practical preparation resources include Singapore’s Quantum-Safe Migration Handbook and Quantum Readiness Index, the U.S. CISA/NSA/NIST quantum-readiness guidance, and the EU coordinated roadmap. These help organizations inventory cryptography, prioritize risks, and plan migration.

A sufficiently capable quantum computer could use a mathematical technique called Shor’s algorithm to defeat public-key algorithms such as RSA, Diffie–Hellman, ECDH, and ECDSA. For data platforms and applications, this affects secure connection setup, protection of encryption keys, certificates, and digital signatures. Where controls depend on these vulnerable algorithms, quantum attacks could undermine the confidentiality, integrity, authentication, and transmission-security objectives addressed by NIST CSF, SOC 2, HIPAA, and HITRUST. Traffic captured today could become readable later if its key exchange is vulnerable: the “harvest now, decrypt later” risk.

Digital signatures establish authenticity and detect changes to data. Their uses include certificate authentication, signed tokens and messages, and code signing to verify software and updates. Signatures serve a different purpose from encrypting content to keep it confidential.

Symmetric encryption is affected differently. AES-256 remains a strong choice against currently understood quantum threats. The way its encryption keys are protected and exchanged must also be considered.

Post-quantum algorithms address vulnerable key-establishment and signature mechanisms. The main algorithm families below serve different purposes in the connections, certificates, and custom applications discussed in this document.

Algorithm family	Purpose and application
ML-KEM	Establishes a shared secret, including in hybrid TLS key exchange. Bulk data remains protected by symmetric encryption such as AES.
ML-DSA	Creates and verifies lattice-based signatures for certificates, signed tokens, and application data, where supported.
SLH-DSA	Creates and verifies hash-based signatures for application data and other signed content. TLS limitations are explained below.

We are closely tracking standards and government guidance and working with our platform and technology partners to align adoption. Our current roadmap targets full post-quantum readiness in InterSystems IRIS in 2027, including expanded signature support and controls for configuring and monitoring PQC. These platform capabilities provide the foundation for adoption across our products and services.

This work builds on the platform’s use of OpenSSL for cryptography and TLS. OpenSSL 3.5 already supports ML-KEM, ML-DSA, and SLH-DSA. InterSystems IRIS on Windows uses OpenSSL 3.5 starting with release 2026.1; subsequent releases have also been tested against OpenSSL 3.5. On Linux, InterSystems IRIS uses the library supplied by the operating system, so available capabilities depend on that library and its configuration.

InterSystems IRIS databases support AES encryption with 128-, 192-, and 256-bit keys. AES-256 has been the default for new database encryption configurations since InterSystems IRIS 2025.2. Upgrades do not change existing settings, so customers should confirm the encryption strength used for existing databases and backups and review how their keys are protected.

Our 2027 platform roadmap includes online encryption of previously unencrypted databases and online re-encryption of existing databases. This is intended to help customers move to AES-256 without taking their databases offline.

At the IRIS platform level, hybrid TLS key exchange is already available using OpenSSL 3.5 or later. With TLS 1.3 and compatible endpoint policies, the default group X25519MLKEM768 combines conventional X25519 key exchange with ML-KEM-768. Hybrid key exchange protects connection confidentiality against future quantum decryption while allowing continued use of conventional certificates.

Custom integrations using %Net.HttpRequest can benefit through their selected SSLConfiguration without changes to request code. For database connections, web access, and outbound integrations, confirm that both endpoints support hybrid key exchange and verify the group actually negotiated. Where a proxy or gateway terminates TLS, check both the connection to the gateway and the onward connection to the application.

Certificate authentication has a separate migration path. ML-DSA certificates can be used with compatible OpenSSL 3.5+ endpoints and trust chains; certificate authorities, clients, and validating software must support the chosen algorithms. SLH-DSA is available for cryptographic operations but is not supported for TLS authentication in OpenSSL 3.5 or 3.6.

Planned configuration and monitoring enhancements will help customers select and verify the algorithms used by their connections. Application signatures and signed tokens also need compatible software support; a TLS upgrade alone does not change the cryptography used inside application messages.

Customers writing custom applications should identify direct cryptographic calls and the systems that consume their outputs. The examples below use $SYSTEM.Encryption methods to show what to review in applications built on IRIS.

Area and examples	What organizations should review
Symmetric encryption AESCBCManagedKeyEncrypt() AESGCMEncrypt()	Managed AES keys may be 128, 192, or 256 bits. CreateEncryptionKey() defaults to 128 bits when length is omitted; specify 32 bytes (256 bits) explicitly. This application API default is separate from the database encryption default.
Public-key encryption RSAEncrypt() / RSADecrypt()	Plan to replace RSA-based data or key protection as supported PQC interfaces become available. Include RSA key transport in JWE and XML Encryption. Changing RSA padding does not address the quantum risk; migration may require updated key handling and data formats.
Digital signatures RSASHASign() / RSASHAVerify() RSASSAPSSSign() / RSASSAPSSVerify() ECSHASign() / ECSHAVerify()	Review signing and verification together. RSA and ECDSA require migration to post-quantum signatures; RSASHA3Sign() still uses RSA. Plan coordinated updates for the applications and partners that verify your signatures.
Certificate validation X509VerifyCertChain()	Test the complete certificate chain with the clients, servers, and trust stores in your deployment. ML-DSA chain validation is available with compatible OpenSSL 3.5+ providers, but every required verifier must support the certificate algorithms.

Customers should also review cryptography used by identity providers, messaging partners, file-transfer services, and key managers. The examples below identify dependencies to include in upgrade and interoperability testing.

Area	What customers need to know and do
JOSE, OAuth 2.0, and JWT %Net.JSON.JWA %Net.JSON.JWS %Net.JSON.JWK	RSA (RS*/PS*) and ECDSA (ES*) token signatures require coordinated migration by issuers and verifiers. ML-DSA identifiers are standardized in RFC 9964; confirm support in your product release and identity provider before using them.
XML signatures, WS-Security, and SAML	Identify RSA-based signatures and RSA key transport in XML Encryption. Coordinate migration with identity and messaging partners as compatible algorithms and protocol support become available. Test both message creation and validation.
SSH and SFTP %Net.SSH.Session SetPreferredAlgorithms()	Post-quantum SSH and SFTP key exchange is planned in the 2027 platform roadmap. We will provide the required library updates through supported releases. Customers should plan the appropriate product upgrade and confirm compatibility with their SSH and SFTP servers.
KMIP and external key management	Where KMIP is used, IRIS can create and retrieve AES keys. Confirm the strength of those keys and assess the TLS connection to the external key manager separately. Coordinate testing with the key-management provider.
FIPS mode	The validated providers currently used in IRIS FIPS deployments do not include PQC algorithms. Customers with FIPS requirements should confirm which algorithms are available in their approved configuration and account for validated provider availability in migration plans.

Quantum readiness depends on the complete environment. Begin with an inventory of your InterSystems products and services, releases, deployment models, certificates, integrations, and custom cryptographic code. Identify which components your organization manages and which depend on InterSystems or another provider.Operational responsibilities depend on whether the deployment is customer-managed or delivered as a managed service.

InterSystems responsibilities

• Deliver supported PQC capabilities and migration guidance through product and service updates.
• Coordinate with technology partners and validate interoperability in supported configurations.
• Help customers understand release-specific capabilities and plan migration through the Worldwide Response Center (WRC).

Customer responsibilities

• Inventory products, services, releases, certificates, integrations, and custom cryptographic code.
• Prioritize data with long confidentiality requirements and identify applicable migration deadlines.
• Plan upgrades and configuration changes with the responsible provider; update customer-managed systems and custom applications.
• Test connections, certificate validation, and application signatures with connected-system providers.

For questions about PQC, product capabilities, or timelines, contact the InterSystems Worldwide Response Center through WRC Direct or support@intersystems.com. Include your product or service, release, deployment model, affected connections, and required timeline so we can involve the appropriate specialists.