Post-Quantum Readiness: Preparing a Data Sharing Ecosystem

August 6, 2026 · 13 min read

Erick Domingues

Country Manager (Brazil)

Ralph Bragg

Chief Technology Officer

Digital signatures are fundamental to an Open Finance ecosystem. They are used to authenticate participants, protect payment instructions, and confirm that messages have not been altered.

Quantum computing will eventually weaken the algorithms commonly used for these signatures. Replacement algorithms are now standardised, but adopting them is not simply a technical upgrade. It requires an entire ecosystem of independent participants to move in the correct order without affecting existing services.

That is the immediate post-quantum challenge that must be tackled by data sharing ecosystems.

Why ecosystems need to prepare now

A sufficiently capable quantum computer could compromise RSA and elliptic curve cryptography, allowing an attacker to derive private keys and forge signatures.

NIST standardised the first post-quantum signature algorithms in 2024. However, the immediate reason to begin preparing is not the expected arrival date of quantum computers. It is interoperability.

A participant cannot safely add a post-quantum key to its published key set unless every system consuming that key set can process it correctly.

RFC 7517 states that consumers should ignore key types they do not recognise. In practice, many libraries reject the complete key set when they encounter a single unsupported key.

Raidiam tested the JWT libraries listed on jwt.io. Of the 46 libraries that parse a JWKS, 19 rejected the entire set when an ML-DSA key was included. This represented 41% of the libraries tested, with particularly high failure rates in some language ecosystems.

This creates an unusual risk. The participant publishing the new key may continue to operate normally, while its counterparties fail. A strict consumer may stop accepting every signature from that participant, including signatures produced using existing classical keys.

We have already observed this behaviour in a pre-production environment. An issuer added post-quantum keys to its JWKS and a downstream consumer rejected all requests. The tokens were still signed using a classical algorithm. The presence of the additional key was enough to cause the failure.

This is why the transition must start with consumer readiness rather than key issuance.

Regulatory expectations are developing

Regulators are also beginning to set expectations. The Central Bank of the UAE has instructed banks to be ready for post-quantum cryptography by 2028, and post-quantum readiness is increasingly appearing in procurement and RFP requirements.

The algorithm change itself is relatively straightforward. The longer task is ensuring that every participant has upgraded its libraries, validated its infrastructure, and demonstrated interoperability. For a large ecosystem, this requires a structured multi-year programme.

Where signatures are used

Within an Open Finance ecosystem, signatures are commonly used for:

Authentication : private_key_jwt client authentication request
Trust & Registration : software statements assertions and federation entity statements
Non-Repudiation : Signed payloads for consent requests and payment initiation
Identity : ID tokens
Authorisation : JWT based access tokens

Each signature is verified by another participant using its own technology stack and upgrade cycle. There is no single point at which the ecosystem can centrally change its algorithms.

Current FAPI 1 and FAPI 2 profiles restrict signing to PS256 and ES256. As a result, ML-DSA keys do not yet have a permitted use within those profiles. Publishing them in a shared production JWKS therefore introduces compatibility risk without providing an immediate functional benefit.

Initial readiness activity should remain in controlled sandbox environments until the relevant profiles and participant implementations are ready.

Raidiam support for ML-DSA

Raidiam Connect supports ML-DSA, the Module-Lattice Digital Signature Algorithm standardised by NIST under FIPS 204. It is the leading standard for post-quantum digital signatures and the algorithm we would recommend for deployment today.

As with any emerging cryptographic standard, research will continue as adoption grows. This does not undermine the case for ML-DSA. It reinforces the importance of designing trust infrastructure so that it can evolve as standards and security guidance develop.

Raidiam Connect is built with this flexibility in mind. Our PKI is algorithm and cipher dynamic. Should an ecosystem later choose to introduce another post-quantum signature scheme, such as SLH-DSA, it can do so with minor impacts to its trust framework.

ML-DSA can also operate alongside existing RSA and elliptic-curve algorithms. This allows current keys and integrations to remain in place while post-quantum capabilities are introduced in a controlled and gradual manner.

The standard defines three parameter sets:

ML-DSA-44
ML-DSA-65
ML-DSA-87

Raidiam supports all three, with acceptance configurable by environment. A sandbox profile can support the full set for interoperability testing, while a production profile can be restricted according to the ecosystem's security policy.

The directory can issue and accept ML-DSA signed JWTs for software statements, notifications, and key distribution. The OP can accept ML-DSA signed private_key_jwt assertions, request objects, and ID tokens. Public keys can be registered through the existing JWKS and PEM upload processes.

A post-quantum key is represented in a JWKS using the AKP key type defined in RFC 9964:

{
  "kty": "AKP",
  "alg": "ML-DSA-87",
  "kid": "2026-directory-mldsa-1",
  "pub": "7yYpnG4RERQ2tJEdIrP1MMHi0wVP1NqzhgTWS8tKcPbYfMoR...n5UNFRQ-zLsliSxpLtSTgO4X"
}

The pub value is truncated here for readability. The full ML-DSA-87 public key is 2,592 bytes, or 3,456 base64url characters.

Issuing a post-quantum certificate

Raidiam already fully supports the ML-DSA algorithm and is capable of deploying this PKI capability on any live or new Trust Framework deployment.

For testing purposes, Raidiam also makes available a tool to test the creation of ML-DSA certificates that can be made available on request. This tool generates a keypair, builds a PKCS#10 CSR, and asks the test CA to sign it.

Generating a keypair and issuing an ML-DSA certificate from the Raidiam test PKI

A real ML-DSA certificate

The issued certificate is an ordinary X.509 certificate. The only difference is the algorithm: both the subject public key and the CA's signature are ML-DSA-87. Revocation works exactly as it does today, through the OCSP and CRL endpoints published in the certificate.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            4a:d2:4e:58:3e:9a:b6:81:7f:7c:96:34:bc:2d:58:dc:23:1b:fb:05
        Signature Algorithm: ML-DSA-87
        Issuer: C=UK, O=Raidiam Services Limited, OU=Raidiam,
                CN=Raidiam MLDSA Test Issuing CA - G1
        Validity
            Not Before: Aug  6 04:08:00 2026 GMT
            Not After : Sep  5 04:08:00 2027 GMT
        Subject: C=UK, O=Raidiam,
                 OU=71511b92-94f8-484e-920a-79a31ee340c5,
                 CN=6378ad17-322b-4038-b82a-fa2682cb211c
        Subject Public Key Info:
            Public Key Algorithm: ML-DSA-87
                ML-DSA-87 Public-Key:
                pub:
                    ef:26:29:9c:6e:11:11:14:36:b4:91:1d:22:b3:f5:
                    30:c1:e2:d3:05:4f:d4:da:b3:86:04:d6:4b:cb:4a:
                    ... (2,592 bytes)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            Authority Information Access:
                OCSP - URI:http://ocsp.pki.mldsa-test.poc.raidiam.xyz
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl.pki.mldsa-test.poc.raidiam.xyz/issuer.crl
    Signature Algorithm: ML-DSA-87

Full certificate (PEM)

An SSA signed with ML-DSA

The directory issues software statements signed with ML-DSA. The JOSE header of a real sandbox SSA shows the algorithm in use:

{
  "kid": "ML_DSA_87_signer",
  "typ": "JWT",
  "alg": "ML-DSA-87"
}

The token itself is a standard compact JWT. What changes is the proportion: the payload carries 33 claims in 3,816 bytes, while the ML-DSA-87 signature alone is 4,627 bytes. The signature accounts for 54% of an 11,335 character token.

Full SSA (compact JWT, 11,335 characters)

eyJraWQiOiJNTF9EU0FfODdfc2lnbmVyIiwidHlwIjoiSldUIiwiYWxnIjoiTUwtRFNBLTg3In0.eyJzb2Z0d2FyZV9qd2tzX2luYWN0aXZlX3VyaSI6Imh0dHBzOi8va2V5c3RvcmUuc2FuZGJveC5yYWlkaWFtLmlvLzM3OGVmNzE2LWU2MjEtMTFlYi1iYTgwLTAyNDJhYzEzMDAwNC83Yzc0N2I1My05ZjBhLTRjNzYtYWFjMS0wMTM0ODYyZDhlZWMvaW5hY3RpdmUvYXBwbGljYXRpb24uandrcyIsInNvZnR3YXJlX21vZGUiOiJMaXZlIiwic29mdHdhcmVfcmVkaXJlY3RfdXJpcyI6WyJodHRwczovL3d3dy5leGFtcGxlLmNvbSJdLCJzb2Z0d2FyZV9zdGF0ZW1lbnRfcm9sZXMiOlt7InJvbGUiOiJDeXByZXNzIEFjY2VzcyIsImF1dGhvcmlzYXRpb25fZG9tYWluIjoiQ3lwcmVzcyBBY2Nlc3MiLCJzdGF0dXMiOiJBY3RpdmUifV0sIm9yZ19qd2tzX3RyYW5zcG9ydF91cmkiOiJodHRwczovL2tleXN0b3JlLnNhbmRib3gucmFpZGlhbS5pby8zNzhlZjcxNi1lNjIxLTExZWItYmE4MC0wMjQyYWMxMzAwMDQvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9jbGllbnRfbmFtZSI6IkNsaWVudE5hbWUiLCJvcmdfc3RhdHVzIjoiQWN0aXZlIiwiaXNzIjoiUmFpZGlhbSBTU0EgaXNzdWVyIiwib3JnX2p3a3NfdHJhbnNwb3J0X2luYWN0aXZlX3VyaSI6Imh0dHBzOi8va2V5c3RvcmUuc2FuZGJveC5yYWlkaWFtLmlvLzM3OGVmNzE2LWU2MjEtMTFlYi1iYTgwLTAyNDJhYzEzMDAwNC9pbmFjdGl2ZS90cmFuc3BvcnQuandrcyIsInNvZnR3YXJlX2p3a3NfdHJhbnNwb3J0X2luYWN0aXZlX3VyaSI6Imh0dHBzOi8va2V5c3RvcmUuc2FuZGJveC5yYWlkaWFtLmlvLzM3OGVmNzE2LWU2MjEtMTFlYi1iYTgwLTAyNDJhYzEzMDAwNC83Yzc0N2I1My05ZjBhLTRjNzYtYWFjMS0wMTM0ODYyZDhlZWMvaW5hY3RpdmUvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9ncmFudF90eXBlcyI6WyJjbGllbnRfY3JlZGVudGlhbHMiLCJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTpqd3QtYmVhcmVyIl0sInNvZnR3YXJlX2lkIjoiN2M3NDdiNTMtOWYwYS00Yzc2LWFhYzEtMDEzNDg2MmQ4ZWVjIiwic29mdHdhcmVfc3RhdHVzIjoiQWN0aXZlIiwic29mdHdhcmVfc2NvcGUiOiJhZGRyZXNzIHBob25lIG9wZW5pZCBvZmZsaW5lX2FjY2VzcyBwcm9maWxlIGRpcmVjdG9yeTp3ZWJzaXRlIGVtYWlsIiwic29mdHdhcmVfZW52aXJvbm1lbnQiOiJTYW5kYm94Iiwic29mdHdhcmVfdmVyc2lvbiI6IjEuMDAiLCJzb2Z0d2FyZV9hcGlfd2ViaG9va191cmlzIjpbXSwib3JnX25hbWUiOiJNaWNoYWVsJ3MgVGVzdCBPcmciLCJzb2Z0d2FyZV9mbGFncyI6eyJDeXByZXNzXzE4XzAyXzIwMjZfZmFmZjFhZGIwIjpbIkN5cHJlc3NfMThfMDJfMjAyNl9mYWZmMWFkYjAiXSwiQ3lwcmVzc18xM18wMl8yMDI2X2VhYzI0MjU2MiI6WyJDeXByZXNzXzEzXzAyXzIwMjZfZWFjMjQyNTYyIl0sIkN5cHJlc3NfMThfMDJfMjAyNl85NGViZGFmYTYiOlsiQ3lwcmVzc18xOF8wMl8yMDI2Xzk0ZWJkYWZhNiJdfSwiaWF0IjoxNzg1OTY1NDM2LCJzb2Z0d2FyZV9zZWN0b3JfaWRlbnRpZmllcl91cmkiOiJodHRwczovL2tleXN0b3JlLnNhbmRib3gucmFpZGlhbS5pby8zNzhlZjcxNi1lNjIxLTExZWItYmE4MC0wMjQyYWMxMzAwMDQvN2M3NDdiNTMtOWYwYS00Yzc2LWFhYzEtMDEzNDg2MmQ4ZWVjL3JlZGlyZWN0X3VyaXMuanNvbiIsInNvZnR3YXJlX2NsaWVudF9pZCI6Imh0dHBzOi8vcnAuc2FuZGJveC5yYWlkaWFtLmlvL29wZW5pZF9yZWx5aW5nX3BhcnR5LzdjNzQ3YjUzLTlmMGEtNGM3Ni1hYWMxLTAxMzQ4NjJkOGVlYyIsIm9yZ19qd2tzX2luYWN0aXZlX3VyaSI6Imh0dHBzOi8va2V5c3RvcmUuc2FuZGJveC5yYWlkaWFtLmlvLzM3OGVmNzE2LWU2MjEtMTFlYi1iYTgwLTAyNDJhYzEzMDAwNC9pbmFjdGl2ZS9hcHBsaWNhdGlvbi5qd2tzIiwib3JnYW5pc2F0aW9uX2ZsYWdzIjp7fSwic29mdHdhcmVfandrc190cmFuc3BvcnRfdXJpIjoiaHR0cHM6Ly9rZXlzdG9yZS5zYW5kYm94LnJhaWRpYW0uaW8vMzc4ZWY3MTYtZTYyMS0xMWViLWJhODAtMDI0MmFjMTMwMDA0LzdjNzQ3YjUzLTlmMGEtNGM3Ni1hYWMxLTAxMzQ4NjJkOGVlYy90cmFuc3BvcnQuandrcyIsInNvZnR3YXJlX29yaWdpbl91cmlzIjpbXSwic29mdHdhcmVfbG9nb191cmkiOiJodHRwczovL2RhdGEuc2FuZGJveC5yYWlkaWFtLmlvL2xvZ29zLzM3OGVmNzE2LWU2MjEtMTFlYi1iYTgwLTAyNDJhYzEzMDAwNC9zb2Z0d2FyZXN0YXRlbWVudHMvN2M3NDdiNTMtOWYwYS00Yzc2LWFhYzEtMDEzNDg2MmQ4ZWVjLnBuZyIsIm9yZ19pZCI6IjM3OGVmNzE2LWU2MjEtMTFlYi1iYTgwLTAyNDJhYzEzMDAwNCIsIm9yZ19qd2tzX3VyaSI6Imh0dHBzOi8va2V5c3RvcmUuc2FuZGJveC5yYWlkaWFtLmlvLzM3OGVmNzE2LWU2MjEtMTFlYi1iYTgwLTAyNDJhYzEzMDAwNC9hcHBsaWNhdGlvbi5qd2tzIiwib3JnX251bWJlciI6IjE3ODc5NTIxMTM1MjczMTQiLCJzb2Z0d2FyZV9qd2tzX3VyaSI6Imh0dHBzOi8va2V5c3RvcmUuc2FuZGJveC5yYWlkaWFtLmlvLzM3OGVmNzE2LWU2MjEtMTFlYi1iYTgwLTAyNDJhYzEzMDAwNC83Yzc0N2I1My05ZjBhLTRjNzYtYWFjMS0wMTM0ODYyZDhlZWMvYXBwbGljYXRpb24uandrcyIsInNvZnR3YXJlX3JvbGVzIjpbIkN5cHJlc3MgQWNjZXNzIl0sIm9yZ2FuaXNhdGlvbl9jb21wZXRlbnRfYXV0aG9yaXR5X2NsYWltcyI6W3siYXV0aG9yaXNhdGlvbl9kb21haW4iOiJBbiBBY3RpdmUgRG9tYWluIiwiYXV0aG9yaXNhdGlvbnMiOltdLCJyZWdpc3RyYXRpb25faWQiOiJoZ2UxMjM0IiwiYXV0aG9yaXR5X25hbWUiOiJhdXRob3Jpc2F0aW9uLW1pZ3JhdGlvbi1ob2xkZXIiLCJhdXRob3JpdHlfaWQiOiJjNDEwNTA3My0zMmI1LTQ4ZDgtYjRkMS1hYjRhNmE1N2E2YjIiLCJhdXRob3Jpc2F0aW9uX3JvbGUiOiJQQUdUTyIsImF1dGhvcml0eV9jb2RlIjoiMTc3NTY4MjkzMDAyMCIsInN0YXR1cyI6IkluYWN0aXZlIn0seyJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6IjAwIiwiYXV0aG9yaXNhdGlvbnMiOlt7Im1lbWJlcl9zdGF0ZSI6IlVTIn0seyJtZW1iZXJfc3RhdGUiOiJKUCJ9XSwicmVnaXN0cmF0aW9uX2lkIjoiYnQ2NDc0MzVoZzM0djUiLCJhdXRob3JpdHlfbmFtZSI6ImF1dGhvcmlzYXRpb24tbWlncmF0aW9uLWhvbGRlciIsImF1dGhvcml0eV9pZCI6ImM0MTA1MDczLTMyYjUtNDhkOC1iNGQxLWFiNGE2YTU3YTZiMiIsImF1dGhvcmlzYXRpb25fcm9sZSI6IkN5cHJlc3NfMDhfMDhfMjAyNV9lZGEyZmFlYWUiLCJhdXRob3JpdHlfY29kZSI6IjE3NzU2ODI5MzAwMjAiLCJzdGF0dXMiOiJBY3RpdmUifSx7ImF1dGhvcmlzYXRpb25fZG9tYWluIjoiMDAiLCJhdXRob3Jpc2F0aW9ucyI6W10sInJlZ2lzdHJhdGlvbl9pZCI6IjEyMzQ1Njc4OSIsImF1dGhvcml0eV9uYW1lIjoiYXV0aG9yaXNhdGlvbi1taWdyYXRpb24taG9sZGVyIiwiYXV0aG9yaXR5X2lkIjoiYzQxMDUwNzMtMzJiNS00OGQ4LWI0ZDEtYWI0YTZhNTdhNmIyIiwiYXV0aG9yaXNhdGlvbl9yb2xlIjoid2hhdGV2ZXJvbGUiLCJhdXRob3JpdHlfY29kZSI6IjE3NzU2ODI5MzAwMjAiLCJzdGF0dXMiOiJJbmFjdGl2ZSJ9LHsiYXV0aG9yaXNhdGlvbl9kb21haW4iOiJDeXByZXNzIEFjY2VzcyIsImF1dGhvcmlzYXRpb25zIjpbXSwicmVnaXN0cmF0aW9uX2lkIjoiMSIsImF1dGhvcml0eV9uYW1lIjoiYXV0aG9yaXNhdGlvbi1taWdyYXRpb24taG9sZGVyIiwiYXV0aG9yaXR5X2lkIjoiYzQxMDUwNzMtMzJiNS00OGQ4LWI0ZDEtYWI0YTZhNTdhNmIyIiwiYXV0aG9yaXNhdGlvbl9yb2xlIjoiQ3lwcmVzcyBBY2Nlc3MiLCJhdXRob3JpdHlfY29kZSI6IjE3NzU2ODI5MzAwMjAiLCJzdGF0dXMiOiJBY3RpdmUifV19.06Nd4oMoYXVWl8i-g2GT4Y-2wgcNCzaAsFYDf1FIKeD2UzF9IhJaD0IaVLZXU6iaAGgojKzJA3Yi6cHzMvjS6LDeFdGqpUZG5i10rIaTOp4kPPvo_AaWYI9VDucX7iy2nCq8xuOmP2qOqxm8diBUS6jjz7j0w82XGb4ji475SJAYVeMSDsOp1Lf-5-Nn5S7lOEzbnh9OH0W4O6ud4g0ADwd-_wSFywIHhSQTRH7Xj7pezBPm9leBTlJSpNZBPQEmUH2GMsWw73mk2mYJDPueAdBXiczcrXiadDAmteL5n7WmjFbxKtMB_EFRqif1sEEu0ugFWQr-J0EIl9BtkH0piCuWeZBDt-GHTuPzOeI_RIoDqey8nwAtD52GFt_ekXu932l7ldHm0jPdqPsvdIERmVneb7NFiyuPcqdMnHhkMms-5jov1tG6rjQmmNoZSNqR3eBk45tK2_k26tM1_NYSKJh_ssi51d4C63CmRD35s2MjuNGzEWYTA2SglInd2tr2RcWFt-QWIFaptKXz8ndeDJDd9IGj-KwTv2NAA_aw1hcQpteVHH4mIwWuFkbyV6FBYuchN_1AR8E0G9iersAcPkOszL4YzPmLPdX_7jvW2TC9NJwfyCg4O60YJ0MRRA415AgbESPZsAgCg8ULm-D88jnfIGbpdtkT8E5552bom-aVQiu45GCY6Ma-myNrQrZhBaBALx7B0zqWlXRSNk9_d6XwqnJt5IhOtQR_4uEChEXFKB9QaXIJeuJ75Ae5ZKeHUX8Bxr5cWH5cVYcyL63uzRj_141jp9PjQX82ZgvuUAVx6TY-JCQNKmaZUSB1IY8yaUs3ZvxvPPeM8vLzg-XLHBdNXjJcTOcDSbg_y1tDyIkYVIh7_OBcs6tyav_KvysMRAFQbu7JW5XW88g5jm6tgOS-CyLANLA3LBCN9tIqlXa6ohdR9o0o7C-FMlLZJ2gDvlQt7ojOv7FhvIpFTSuo_-P-l4xmrgUlAiVY5tO6jpGhn1jixiMACutn7bErwttYhJPdhoAltBy7i4qRwDanxD5LhInB5bPOroLTqbf2ZkcQd95Xvoc66IxYprPqsZzZf6T3zDkJ4vUWfeAgtUga2g6tE38FkNSK8lbB1xoQ_sBIDNzcGv_BaxaQOomX7FKmDcSrb8-fuop4K-2dcd8Cx96otZk_Ufnx4mTlz6BZENUu3b7TebpQD528Jl0VCX0OQoVgIuWYxkMKAzDoen7LNmmNtya6VxU1ACk1crEIl_kDBLVxCDSusdH6yBhzd-HUAcciIHIr9zWvcQWhH3bPFQtfSKu7aPdMwbqvUx1ZuV3fFPjVNf6mbmanE2aa9Hd0bQ0ihNjnmehrUoWn9w7r0L2Bs_iie-_rr1mT3YRjKRSZ3gLfgn72xrEjtd-XCVUqBh3dY9aYtaGzgLJcRCmEz6qEwHrv8Q-Bkz9JatPH8Pg9W8WnZAt2YOqULW55oVqkdT3INT0s9SG3getdo5_afintbWnYcpugWPsWkgRRaYCsguLZAe_fFtLwh-hgev7yPSXsbe2X5B301CgW0CM7PNhr5Un3EW2Fsn4MOsmd3NMEWp0_sinIk_K2mtNSVnp1bCtagdzVBCIoN-w34EDx6gI_d3kAHohZmwUCmWtCxQXzPqRcL1ahM7NpcrN_dEcyRK4XrcA_1L5JCUZAwap7Z1INb-pjrUiJctb7-q_v35x8OmB86bCNrqoefuI4XCHzNeTW-sqTfZn6GMi0y91gF2DUANI9Lpva1lV162UmGin5SFJIJn2_mIJvuqni6QNJmljK8EwhxtWp3kdnk6_Ns1ATUQgjk3Du_Bh0S8Co1zF70zHxWozvB08WMahw3lGPNatdyXn1gVRvpYw-82Ft4tt94leXAS0pYJ75ZuVv3P9RbYuOljE-Z0_VR-MIXGY52jqG-U2cBDpyzllrOCcUnJ5Pu8EAvVQirI-yqftOJo1NopvHgMuV-BkWQPSTACIbEyH9RxyPzEtPtZJQsOayBoLn4zXgK6Mz8cuBf4K1SSkXjaYP3zYGh7wjr4l7X5wDHEBvSPV1-iFk-kCjHtl3dKDju6eO8aqb9mFBoLgUbS-D0VNM5uZ2EGgUX_N4z3XDP3buQ3CkgzfXdSDtsOXnIZQ4DpZSsdSCzWdeBh6qnqssF_DF_Y2OdbkV2luAApsI2ZpsQYcS7aBhSx7Q9uOriOHFRTvHxy5HgU-Pu-wYLpoo-0rIj6s2WZglkJU7bsTnG-5yos0HiEtDGNvfuJC4jYm2LSLxrzpfO8kCCQcnntaDlxkhknz9lSCucC6bvyibaB_fHxoq0JVUjJO2r-6n4oFyt7F_92Oc-ImiRPtV_Sy5f979JMKLXSPl2zSNuTEd07mH-KfRUrDd4TCmXkKD-s056pqsrr52LhsOfKTRpTbr9mtfNo_w9hrSvdSeHh9ClPPUrJUkBjlftCbMtIM6BUqOP3NKwLHnZPgo1sDz8BpbO8fcSa5FwizO_xUbxXCc3KAMLx0JGJfSw_K2r0wdh3gy_wATVByorle8l_C7qcLEhOY0BD4wsIP9zWh4-TjduClrOcCnEUHScT8KneR7035Vsty40xTDFi8WcFDtflPlBNwlP92wTs9-79g0N8WCm8DnXNj0ROPxxzKiQvFD-RI4JvHyLHDIn7-GwQAiW9oDut5_x7_q8bUD_9NvVu36bVsg38Q2570wFz98cjVd9Dhmz7vXKoZ0EbY-DeeQ814UhKj0yafpODrf_Wt-AevJvgnYAfUseeKRlvuZltR_UIEGgW47AuJqC1Gg6poEYrPNE8nCJ1teTNxz19XAOizfIYfCIpZ27EHrWi0vB3ypchM6wYepgVpsUM2qWkLCOfROm0-b2JdpCX5EkaAoZ77A13lw43FI4-kPUuWbXL--TTkXHUhcRAn9lt2W_NM-LLQPN5n9mSpdFZH4G40FVjoVkMxF5oJR7wHw3sUCh0RlNn9L1YIB4NMVAu7HxLXyqZHCQy0G7L72KGA3o03rLBEAd77EwScB_wE3HzyZRlUyaKyHJuNCSx7A4V3SGV7XgWg7fGFC-zP1nJmaXdKOHISnd96Qt-Xu0Y0BJxgaV7s3V9cx5kGqPYNbj6kCjss85MHxsbF4pxcolDDcs2FtV2-p7DVc3rlyV715UrzKMsB2RwLdwBBLZbrs92RUB8CKS1Q_OTWVmSONDm_p_5n-3kiLBqJhFb63SId_Q91MUiZGqqNb1xBNxhEU7IMjjGmE4UKVel8K3gM3jCUrwPri6bSLi0ZpoV7zuIQIo0SxlM4Ojfo3GGrBs5pak_77c45eZivVC6vY-nfa2MbwyOsvr7D6fPtubqDQHrsNfFs5zXpBONKZgrYb8_f24qeJtYXZvaiK1ucdYPCcPVeRC0HOwtoyrlSJGlSZzliZj-8Esw5Ng3bFqar-HEM3QTQPACZ5Y7HjNdHU5K1PpLiNJ0PLe6WhNkmWFa5uu_6y51X4W_jaz15X18240zFy6sI4DA29PXuLDeGg6rxzSkvmefYIBqDzfwuogeL5AXY2CUqxuJYLIBC0B9IsCrH7a3fCRrdKFCOiAY65nFsstCUCQ3ro-6brnwrpwP0ZTpQ5a1m5YhJoapgibIHGHQ2IBpDhh71vYQrC6T5BmWbtkH0PAP_3hCU4kZtM4kvMssoXEqM_saMYjq06wNvEyxBc2OCz3RGkzor9qEzHkyEYgBElTDEuliDhNMM6sjbkI65kD-rDhzDxhYvFIkkpkaHyeuXNGMg-zv7xG6QPkE6Ik6fd7CkDtLHqm-LurKbQyxeERQhmZQIG5gW5729RBKjdower0xsCvDDJOROWU6dqo__EKKJBegcmdYP-Igdj_a0I_X1FCDVvupOPDlIkrxvfLMIudUjzUcenY7ueootlDobqTAuhPfDU-VYjm0sLjxwAQ7ykwK9dkABycQR7rn4ZEkiVElVc--D5nVS_uINMTmkiBcSnNJ5ppbUnNUasMjcCQHaftKZ-P3tPvx_q6aeydHgVrTRKz00HRl0EkyZ8kuv_2UGMIEmnKeurWNjuNsQP6_7f7RsDb0ULkGGRZDrNOfbxDQ5YYOlIXD8wytkRnd43qcJchQoRxcJW_Y2EJuMnGMbCP1OWo9tifIjCVfvny9zHtg2ad9tOHp-uASaxqNUDphnNVK-7a4WW9rXnO5_Uhgp4dCt93tw44o-BR6gYtPPZVFoP1Xn5YGVB9UvrvqNe6QZK-oF7g8Y5Ec0z24OUO4ZElmIgvcwzcfY6xo1kwSsqffVpzj5Ebl1DY595eStN-VNDmQ7o82QmGjA1Zuts_NVAV-OIKmagREO9E6-JNJDcRm7K3FtuAlCYpEw6TPrzz8Dqh9hKo8m9KRQtRvvLN1CudCX79K79c8u-y7_GLWvEoidfxFT99vPTtiBp9cm-TmRrM2-2wsyIBa7dFu9XeXxqpBQ0tmlAtyt2NFqFDPYr_q49cS54kbzhoTnifVJb8Fy6hbekFdFFQ5JTy23ppxzP9wrQPFj0BSQ5zw0T46mAizpk3EJtjtYSgrYznK3TjRKUkzB3gN-CPgklOd6Jh52zXF24TriThqYwgZ7CBo3WqV4BJg2zAJvHfwxCq7K50gbzRFX5rdERZrqeIeoiVQr1hDI8pXL2pf6RXz6bqEOxckQ1sToSQX1Z96JThhT6gjaXdCJd6ojmB3CqFoFHPsyehsYdbeFvbMVUQ0NXL9C4EQwUXZAVWxuiaeCEKbL_kVZU7QioW1sWF86RcGdPXHLu-x3zM_RajRVB0EVgsCwFRhBfROrdA0Yq2lQna3hpkdh26isNWlkbO9V_bk0QwyNcWMDphlEAM3AqkrrUMCKhMk_qWVSbOnySfrfvj5HUjJUL68IhGmcrQkqCevoXn3ELWuCpiqy_zhXOTU8hcarXDeUjcP0ylCxVPt261hC_BMrSlIrHuZ7dtAZEqK4M6lTtcv2sRaiDNXy4a4872odC0SF4GAx0p8Q5z7pL5LytK-nU5ABcKItlD5EbqiclGeUVUUGiMl6NDqonWPi5f-p7NCh6FX1VqExGP0p1Hnsv5As43mRoH4KKIOvFqlc-m_kU7XvaEFmpUDBaVPBsJs2qOyUyIpaccHyWoOJLoLYW41br2Q_V2PMVdw-uM-O3yzkx6dv7MZrxdYlfBN4Y177oAu6WXqZv8xZoOlNh7oEzbOcuwJ5ffXbmFOx1qgOiZxwLwapNTQkjMYmEy_aKb9meGO59CHsEvVroXqtA6_ASIWanWaTyOrkYJ24IziDgx_7wDhi6R1ePF4Gi61nfu25nsKECfGO0S22Ka_YJ2X97wdx4hqDkxJwhCovsFba9CPqY6f9gCdHsGpaQgM9cXvDEaoGn2D0Tlhkfp8zv2FQn6f_GD1HjzJFSqNevlaofZCWxHEuc1NNe9y5JHSUeoXCpo6sSkxdVy9K4SxSNQhnHXaFLFmcs6bWaLPgIwobZwF-eYepMLB6vFPTqihPgWfRrhlk4ymAU5XC6uE95GU2nXArmiVf33eVyt5IokR1sgfJ1jrY8bBtaOXDgYTMQl7NPaXf-W4EXyUW4xG7il1JNqNd-cWJSZl_D9QyDPzXzFMGXZdJac9EBNUZYukNXqochKwtTf80n6gsciMIVw2nUrmfVHf48_S80U8OsscE226z1UHT0BsbZBixn5g6OqeJTXRHE1BaXlPhFWOLz4O49HhgJ4dJX9I-xS-JI5EyaBDR0iw91ytNKPAebiIN7lcQccnHKSA_QU1EZERBYoLpxPO-gSRXs88dkMWLhv44WSfLvaoUpZofCj4ilQbkD-Ap64QBp-OtY9bJ65LNydKO3SfWJ27giJ8Q3qQjhR2Pz0u7BLk2VvnoctpQ_R3ep3dckDg0byRJZjrYkomgOqXcgqvSkq6DX-t1GYthbjq59hJkZYaZLQofI4dZROWN_ePwEC-FYsnAk-dmfGq70iWvnZ1SH5e-LUzsV-a8B_JiMQ0I0DSth8uSL-ZjiJroVKxSmOL8QiO7YrUcLTe6b5e8JiPdPHMZB7APLQGKq4Qd069VKXcJrRBFYZcKqhkYxUdoZAO7TEL1FUWt2jbCxsvH0_F1zobPE_wMRas7mDBozQmOEiL_4Q09bXHGKtr_eEGOVvPv-LHCN7ZGVrLjI8QAAAAAAAAAAAAAAAAAAAAAAAAALERYfKC4yOA

A practical transition approach

The transition should be additive. Existing cryptography remains available while post-quantum capability is introduced in parallel.

1. Confirm tolerance of unknown keys

Every component that consumes a JWKS must be tested first. An unsupported key must be ignored without affecting recognised keys in the same set.

This should include a strong testing framework to ensure that data receivers on the ecosystem are capable of ignoring those keys.

2. Introduce post-quantum infrastructure in parallel

A post-quantum PKI can be deployed alongside the existing PKI without changing current certificates or participant integrations.

Hybrid models can also support the transition. For example, post-quantum roots or intermediates may initially issue classical leaf certificates while the wider ecosystem develops support.

3. Enable verification before issuance

Participants must be capable of accepting ML-DSA signatures before any participant begins issuing them.

The sequencing principle is simple: everyone must be able to read before anyone starts to write.

This again is where testing becomes needed.

4. Begin controlled issuance

Once compatibility has been demonstrated, ML-DSA keys and signatures can be introduced through sandbox testing and controlled participant groups before broader production adoption.

5. Tighten the production profile

After adoption, the ecosystem can restrict permitted parameter sets and define a timetable for reducing reliance on classical algorithms.

Participant impact

ML-DSA signing and verification performance is suitable for typical Open Finance transaction volumes. The more significant impact is message size.

	RSA 2048	ML-DSA
Public key	A few hundred bytes	Approximately 1.3 to 2.6 KB
Signature	256 bytes	Approximately 2.4 to 4.6 KB

The examples above sit at the top of those ranges because they use ML-DSA-87, the largest parameter set. The certificate is 8,201 bytes against 855 bytes for an equivalent RSA-2048 certificate, its public key is 2,592 bytes against 294, and the SSA signature is 4,627 bytes against 256.

Participants should review:

HTTP request and header limits
API gateways and reverse proxies
Logging and storage of signed messages
HSM and KMS support
Certificate profiles
Cryptographic libraries

For signed message payloads, the increased signature size is particularly relevant because signed request objects may pass through several infrastructure layers before reaching the authorisation server.

JWT based access tokens deserve particular attention. They are presented in an HTTP Authorization header on every API call, which is exactly where request and header size limits are enforced.

Compatibility with unknown key types should also become part of ecosystem conformance and certification. Testing this centrally with a strong testing Framework is more reliable than waiting for individual participants to report failures after keys have been published.

Starting the transition

Ecosystem operators should begin by testing mixed classical and post-quantum key sets in sandbox. Participants can then register ML-DSA keys, exercise the relevant signature flows, and identify infrastructure or library constraints.

The transition plan should work backwards from the applicable regulatory or ecosystem deadline, allowing sufficient time for participant remediation, conformance testing, and controlled production adoption.

Post-quantum migration is an ecosystem interoperability programme, and the order in which changes are introduced will determine whether the transition is controlled or disruptive.

This is also a fast-moving field. The standards, the regulatory expectations, and the cryptanalysis behind them are all still developing, and we will keep monitoring them and keeping the platform current as they do. For a trust services provider that is part of the job.

Raidiam can support ecosystem operators in assessing readiness, testing participant compatibility, and planning the transition to ML-DSA. If there is a capability you need that we do not yet offer, tell us and we will look at it.

Why ecosystems need to prepare now​

Regulatory expectations are developing​

Where signatures are used​

Raidiam support for ML-DSA​

Issuing a post-quantum certificate​

A real ML-DSA certificate​

An SSA signed with ML-DSA​

A practical transition approach​

1. Confirm tolerance of unknown keys​

2. Introduce post-quantum infrastructure in parallel​

3. Enable verification before issuance​

4. Begin controlled issuance​

5. Tighten the production profile​

Participant impact​

Starting the transition​