Post-Quantum Authenticatie voor Game Servers: ML-DSA Migratie Runbook met Code en Prestatiedata

De cryptografische handtekeningen die de TLS-verbindingen van je game server authenticeren, zijn één algoritmische doorbraak verwijderd van vervalsbaarheid. RSA-2048 en ECDSA-P256 — de certificaatalgoritmen die spelersgegevens beschermen tussen je CDN en je origin server — bezwijken voor Shor's algoritme op een voldoende krachtige quantumcomputer. Niet theoretisch. Op een tijdlijn waar Microsoft, Google en de Amerikaanse overheid in 2026 actief omheen plannen.

Cloudflare heeft zojuist post-quantum authenticatie voor origin-verbindingen uitgerold met ML-DSA (Module-Lattice-Based Digital Signature Algorithm), gestandaardiseerd als FIPS 204. Dit is de eerste productie-implementatie van PQ-authenticatie op schaal — op een netwerk dat ruwweg 20% van het webverkeer afhandelt. Als je game backend achter een TLS-terminerende laag zit, raakt deze migratie jouw infrastructuur. En hoe eerder je begint, hoe minder pijnlijk de overgang.

Dit bericht is je runbook: wat er breekt, hoe je het detecteert, hoe je het herstelt met echte commando's en code, en hoe je voorkomt dat je game backend de zwakke schakel wordt.

Waarom Game Servers Uniek Kwetsbaar Zijn

Game backends zijn geen typische webservices. Ze onderhouden persistente verbindingen voor real-time synchronisatie van de spelstatus, slaan maanden of jaren aan spelersvoortgangsgegevens op, en verwerken gevoelige operaties zoals inventorybeheer en betalingsverwerking. Het dreigingsmodel voor post-quantum aanvallen tegen game servers is concreet:

• Spelerscredentials en sessietokens die tussen je CDN-proxy en origin API stromen
• In-game economiegegevens — virtuele valutasaldo's, iteminventarissen, handelsgeschiedenissen die op secundaire markten echt geld waard zijn
• Betaalwebhooks als je backend aankopen server-side verwerkt
• Anti-cheat signalen die, eenmaal blootgelegd, aanvallers in staat stellen je detectieheuristieken te reverse-engineeren

De aanval waartegen we ons beschermen is geen passieve gegevensverzameling. Het is actieve impersonatie: een quantum-capabele aanvaller die de authenticatiecredentials van je CDN vervalst en kwaadaardige payloads rechtstreeks in je game API injecteert. Dat is een fundamenteel andere dreiging dan "harvest now, decrypt later."

We hebben gedocumenteerd wat er gebeurt als backend-beveiligingsarchitectuur onder druk faalt — post-quantum authenticatie is de volgende evolutie van diezelfde verdedigingshouding. De vraag is niet of je game te maken krijgt met geavanceerde aanvallen, maar of je infrastructuur ze overleeft.

Encryptie vs. Authenticatie: Wat Echt Breekt

Er is een cruciaal onderscheid dat voortdurend wordt verward: post-quantum encryptie en post-quantum authenticatie zijn aparte problemen met verschillende tijdlijnen en oplossingen.

Post-quantum encryptie (al uitgerold)

TLS 1.3-sleuteluitwisseling met hybride algoritmen zoals X25519Kyber768 is al breed uitgerold. Cloudflare heeft PQ-encryptie ingeschakeld voor zowel bezoeker-naar-CDN als CDN-naar-origin verbindingen in 2022–2023. Dit beschermt gegevens onderweg tegen harvest-now/decrypt-later aanvallen.

Post-quantum authenticatie (het nieuwe grensgebied)

Authenticatie is waar het echte risico nu ligt. Wanneer je origin server een TLS-certificaat presenteert dat is ondertekend met RSA-2048 of ECDSA-P256, kan een quantumcomputer die Shor's algoritme draait die handtekening in realtime vervalsen. Dit maakt man-in-the-middle aanvallen mogelijk — niet passieve opname, maar actieve onderschepping en manipulatie van je gameverkeer.

Hier is hoe de twee verbindingen in een typische gamearchitectuur eruitzien:

┌─────────────┐    Verbinding 1     ┌─────────────┐    Verbinding 2     ┌─────────────┐
│  Game Client │ ════════════════► │    CDN /    │ ════════════════► │   Origin    │
│  (Player)    │                    │   Proxy     │                    │  (Jouw API) │
└─────────────┘                    └─────────────┘                    └─────────────┘
                                    │                                      │
                              PQ encryptie ✓                        PQ encryptie ✓
                              PQ auth (via MTC, 2027)              PQ auth (ML-DSA, NU)
                                    │
                              Klassieke auth
                              certificaten hier
                              zijn de huidige
                              zwakke schakel

Verbinding 2 — van je CDN of reverse proxy naar je origin — is waar PQ-authenticatie nu uitrolbaar is. Dit is de verbinding die spelersacties, inventory-updates, matchmaking-verzoeken en betaalwebhooks draagt. Als een aanvaller authenticatie op deze verbinding vervalst, hebben ze je backend in handen.

Waarom Verbinding 2 eerst komt

De CDN-naar-origin verbinding heeft structurele voordelen die PQ-authenticatie jaren eerder praktisch maken dan het openbare web:

• Gecontroleerde TLS-client: De CDN regelt connection pooling en handshake-gedrag, waardoor de PQ-overhead wordt verdeeld over duizenden verzoeken
• Bestaande vertrouwensrelatie: Je hebt al een accountrelatie met je CDN — geen afhankelijkheid van de publieke Certificate Authority-ecosysteem
• Aangepaste PKI: Je kunt je eigen certificate authorities draaien, waardoor de beperkingen van de WebPKI en Certificate Transparency-eisen worden vermeden
• Hergebruik van verbindingen: CDN's onderhouden persistente verbindingen naar origins, waardoor PQ-handshakes zelden voorkomen ten opzichte van het totale verzoekvolume

Daarom kan Cloudflare vandaag ML-DSA-authenticatie voor origin-verbindingen uitrollen, terwijl het openbare internet wacht op Merkle Tree Certificates (gericht op 2027).

ML-DSA: Het Algoritme dat PQ-Authenticatie Aandrijft

ML-DSA, gestandaardiseerd als NIST FIPS 204, is gebaseerd op de hardheid van roosterproblemen — wiskundige structuren die geacht worden zowel klassieke als quantumaanvallen te weerstaan. Het is het primaire algoritme dat wordt uitgerold voor post-quantum digitale handtekeningen in de industrie.

Parametersets en beveiligingsniveaus

Parameter Set	Beveiligingsniveau	Publieke sleutel	Handtekening	Handshake overhead
ML-DSA-44	NIST Cat 2 (~AES-128)	1.312 B	2.420 B	~4,5 KB toegevoegd
ML-DSA-65	NIST Cat 3 (~AES-192)	1.952 B	3.293 B	~6,5 KB toegevoegd
ML-DSA-87	NIST Cat 5 (~AES-256)	2.592 B	4.595 B	~9 KB toegevoegd

Ter vergelijking: een ECDSA-P256-handtekening is 64 bytes met een 64-byte publieke sleutel. ML-DSA-44-handtekeningen zijn ongeveer 37x groter. Dat is de primaire afweging, en het getal dat ontwikkelaars nerveus maakt.

ML-DSA-44 is de juiste keuze voor game backends. Het biedt NIST Categorie 2-beveiliging — comfortabele marges tegen bekende quantum- en klassieke aanvallen — terwijl het de meest performante optie is. De grotere handtekeninggrootte is beheersbaar omdat connection pooling ervoor zorgt dat handshakes zelden voorkomen ten opzichte van het totale verkeer.

FIPS 204 seed-formaat: compacte sleutelopslag

ML-DSA-privésleutels ondersteunen een seed-formaat — een 32-byte willekeurige waarde waaruit de volledige privésleutel deterministisch wordt afgeleid:

Seed (32 bytes) ──► Deterministic Expand ──► Volledige privésleutel (2.560 bytes voor ML-DSA-44)

Dit is een praktische winst voor game backend-infrastructuur. In plaats van 2.560-byte privésleutels op te slaan in je secret manager of omgevingsvariabelen, sla je 32 bytes op en leid je de volledige sleutel op aanvraag af. Sleutelrotatie wordt een kwestie van het genereren en distribueren van een nieuwe seed — operationeel veel eenvoudiger dan het beheren van traditioneel RSA-sleutelmateriaal.

Migratie Runbook: Stap voor Stap

Stap 1: Auditeer je huidige TLS-configuratie

Voordat je iets aanraakt, begrijp wat je draait. Controleer de huidige certificaatketen en handtekeningalgoritmen van je origin server:

# Inspecteer het certificaat dat je origin presenteert
openssl s_client -connect your-game-api.example.com:443 \
  -servername your-game-api.example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -text -noout | grep -A2 "Signature Algorithm"

# Controleer ondersteunde TLS-versies en cipher suites
nmap --script ssl-enum-ciphers -p 443 your-game-api.example.com

# Als je mTLS gebruikt, controleer welk clientcertificaat je CDN presenteert
# (vang tijdens een testverzoek met tcpdump of equivalent)
tcpdump -i eth0 -w tls_handshake.pcap port 443 -c 50

Documenteer deze basislijn. Je hebt hem nodig voor terugdraaien en om te bevestigen dat je migratie niets heeft gebroken. Noteer:

• Huidig handtekeningalgoritme (RSA-SHA256, ECDSA-SHA256, etc.)
• Certificaatketendiepte en alle vervaldata
• Of mTLS al in gebruik is
• Ondersteunde TLS-versies (je zou al alleen TLS 1.3 moeten gebruiken)

Stap 2: Genereer ML-DSA-certificaatketens

Je hebt de Open Quantum Safe (OQS) provider voor OpenSSL 3.0+ nodig:

# Installeer OQS provider
git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local ..
make -j$(nproc) && sudo make install

# Inschakelen in openssl.cnf — voeg toe aan [provider_sect]:
# oqsprovider = oqsprovider_sect
# oqsprovider_sect = oqsprovider

# Genereer ML-DSA-44 root CA (10 jaar geldig)
openssl req -x509 -new -newkey mldsa44 \
  -keyout mldsa44-ca.key -out mldsa44-ca.crt \
  -days 3650 -nodes \
  -subj "/CN=Game Backend PQ Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

# Genereer certificaatondertekeningsverzoek voor origin server
openssl req -new -newkey mldsa44 \
  -keyout mldsa44-server.key -out mldsa44-server.csr \
  -nodes -subj "/CN=your-game-api.example.com"

# Onderteken servercertificaat met PQ CA (1 jaar geldig voor rotatiehygiëne)
openssl x509 -req -in mldsa44-server.csr \
  -CA mldsa44-ca.crt -CAkey mldsa44-ca.key \
  -CAcreateserial -out mldsa44-server.crt \
  -days 365 \
  -extfile <(echo "subjectAltName=DNS:your-game-api.example.com")

# Genereer clientcertificaat voor mTLS (identiteit van je CDN)
openssl req -new -newkey mldsa44 \
  -keyout mldsa44-client.key -out mldsa44-client.csr \
  -nodes -subj "/CN=CDN Proxy Client"

openssl x509 -req -in mldsa44-client.csr \
  -CA mldsa44-ca.crt -CAkey mldsa44-ca.key \
  -CAcreateserial -out mldsa44-client.crt -days 365

# Verifieer de keten
openssl verify -CAfile mldsa44-ca.crt mldsa44-server.crt
openssl verify -CAfile mldsa44-ca.crt mldsa44-client.crt

Sleutelbeheer notitie: Bewaar waar mogelijk de 32-byte seed in plaats van de volledige 2.560-byte privésleutel. Dit vereenvoudigt geheime rotatie en verkleint je aanvalsoppervlak in secret managers en omgevingsvariabelen.

Stap 3: Configureer je origin server voor PQ mTLS

Nginx-configuratie:

server {
    listen 443 ssl;
    server_name your-game-api.example.com;

    # ML-DSA-44 server certificate
    ssl_certificate     /etc/ssl/pq/mldsa44-server.crt;
    ssl_certificate_key /etc/ssl/pq/mldsa44-server.key;

    # Client verification (mTLS) — only trust PQ CA
    ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # TLS 1.3 only — no downgrade to older versions
    ssl_protocols TLSv1.3;

    location /api/ {
        proxy_pass http://game_backend_upstream;
        proxy_set_header X-Client-DN $ssl_client_s_dn;
        proxy_set_header X-Client-Verified $ssl_client_verify;
    }
}

Aangepaste game server in C++ (OpenSSL 3.0 + OQS):

#include <openssl/ssl.h>
#include <openssl/err.h>

SSL_CTX* create_pq_mtls_context() {
    SSL_CTX* ctx = SSL_CTX_new(TLS_server_method());
    if (!ctx) {
        ERR_print_errors_fp(stderr);
        return nullptr;
    }

    // Enforce TLS 1.3 minimum — no version downgrade possible
    SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);

    // Load ML-DSA-44 server certificate
    if (SSL_CTX_use_certificate_file(ctx,
            "/etc/ssl/pq/mldsa44-server.crt",
            SSL_FILETYPE_PEM) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Load ML-DSA-44 private key
    if (SSL_CTX_use_PrivateKey_file(ctx,
            "/etc/ssl/pq/mldsa44-server.key",
            SSL_FILETYPE_PEM) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Verify key matches certificate
    if (SSL_CTX_check_private_key(ctx) != 1) {
        fprintf(stderr, "Key/cert mismatch\n");
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Load PQ CA for client certificate verification
    if (SSL_CTX_load_verify_locations(ctx,
            "/etc/ssl/pq/mldsa44-ca.crt", nullptr) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Require and verify client certificates
    SSL_CTX_set_verify(ctx,
        SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
        nullptr);

    return ctx;
}

// Usage in your game server's accept loop:
void handle_connection(int client_fd, SSL_CTX* ctx) {
    SSL* ssl = SSL_new(ctx);
    SSL_set_fd(ssl, client_fd);

    if (SSL_accept(ssl) <= 0) {
        // Handshake failed — likely client cert issue
        ERR_print_errors_fp(stderr);
        SSL_free(ssl);
        close(client_fd);
        return;
    }

    // Verify client certificate was actually presented
    X509* client_cert = SSL_get_peer_certificate(ssl);
    if (!client_cert) {
        fprintf(stderr, "No client certificate — rejecting\n");
        SSL_shutdown(ssl);
        SSL_free(ssl);
        close(client_fd);
        return;
    }

    // Client authenticated via ML-DSA mTLS — proceed
    X509_free(client_cert);
    // ... handle game protocol ...
}

Stap 4: Werk de vertrouwensopslag van je CDN/proxy bij

Als je Cloudflare gebruikt, upload dan je ML-DS-CA-certificaat naar de Custom Origin Trust Store en configureer Authenticated Origin Pulls met je ML-DSA-clientcertificaat:

1. Upload mldsa44-ca.crt naar de aangepaste vertrouwensopslag van je CDN
2. Upload mldsa44-client.crt en mldsa44-client.key voor geauthenticeerde origin pulls
3. Zet SSL-modus op Full (strict) om certificaatvalidatie tegen je aangepaste vertrouwensopslag af te dwingen

Als je je eigen proxy-infrastructuur draait, moet je het PQ-CA-certificaat naar alle proxy-knooppunten distribueren, clientcertificaten voor elk configureren, en monitoring voor certificaatverval instellen. Dit handmatig beheren over meerdere regio's en schalingsgroepen is waar operationele complexiteit toeneemt — geautomatiseerde certificaatdistributie en -rotatie wordt essentieel.

Stap 5: Test de PQ-handshake

# Verifieer dat ML-DSA mTLS-handshake slaagt
openssl s_client -connect your-game-api.example.com:443 \
  -servername your-game-api.example.com \
  -cert mldsa44-client.crt \
  -key mldsa44-client.key \
  -CAfile mldsa44-ca.crt \
  </dev/null 2>&1 | grep -E "(Verify return|Protocol|Cipher)"

# Verwachte output:
#   Verify return code: 0 (ok)
#   Protocol  : TLSv1.3
#   Cipher    : TLS_AES_256_GCM_SHA384

# Meet handshake-latentie onder belasting
# (pas verbindingssnelheid aan om launch-day omstandigheden te simuleren)
wrk -t4 -c100 -d30s --latency \
  --script=pq_mtls_test.lua \
  https://your-game-api.example.com/api/health

Wat te monitoren tijdens het testen:

• Handshake-latentie: Verwacht 0,5–2 ms extra per nieuwe verbinding ten opzichte van ECDSA-P256
• CPU-gebruik: ML-DSA-handtekeningverificatie is ~2–3x langzamer dan ECDSA-verificatie
• Foutpercentages: Let op certificaatvalidatiefouten tijdens de overgang
• Connection pool-gebruik: Bevestig dat verbindingen worden hergebruikt (handshake-kosten worden verdeeld)

Stap 6: Verwijder klassieke fallbacks

Dit is de stap die daadwerkelijk quantumbeveiliging biedt. Als je origin ook maar enige klassieke (RSA/ECDSA)-authenticatie accepteert, kan een quantum-capabele aanvaller die credentials vervalsen en je PQ-bescherming omzeilen.

Het downgrade-aanvalscenario:

Aanvaller onderschept CDN ↔ Origin handshake
    │
    ├── Dwingt onderhandeling naar klassieke RSA-authenticatie
    ├── Vervalst RSA-handtekening met Shor's algoritme
    └── Doet zich voor als CDN naar je origin server ✓

Je PQ-certificaten zijn waardeloos als er klassieke fallbacks bestaan.

De oplossing: je origin server moet alleen ML-DSA-certificaten vertrouwen voor de CDN-naar-origin verbinding.

# FOUT: Gemengde vertrouwensopslag — klassieke certificaten nog steeds geaccepteerd
ssl_client_certificate /etc/ssl/mixed-ca-bundle.crt;

# GOED: Alleen PQ-vertrouwensopslag — klassieke vervalsingen geweigerd
ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;

Kritieke waarschuwing: Verwijder klassiek vertrouwen pas nadat je hebt bevestigd dat alle CDN-verbindingen PQ-authenticatie gebruiken. Voortijdig verwijderen verbreekt je origin-connectiviteit. Draai de dual-stack configuratie (Stappen 3–5) minimaal twee weken, monitor dat nul verbindingen terugvallen op klassieke authenticatie, voordat je klassiek vertrouwen verwijdert.

Prestatie-impact: Echte Cijfers voor Game Backends

De legitieme zorg: ML-DSA-handtekeningen zijn groot. Dit is wat dat in de praktijk betekent.

Handshake-niveau overhead

Metriek	ECDSA-P256	ML-DSA-44	Verschil
Servercertificaatgrootte	~500 B	~1.700 B	+240%
Handtekeninggrootte	64 B	2.420 B	+3.681%
Totale handshake-bytes	~1,5 KB	~6 KB	+300%
Handshake-latentie (p50)	~1 ms	~2,5 ms	+150%
CPU per handshake-verificatie	~0,05 ms	~0,12 ms	+140%

Waarom dit je game backend niet vernietigt

CDN-naar-origin verbindingen gebruiken connection pooling. Een enkele TLS-verbinding verwerkt duizenden HTTP-verzoeken voordat deze wordt gerecycled. De 1,5 ms extra handshake-latentie wordt verdeeld over, bijvoorbeeld, 10.000 verzoeken — dat is 0,00015 ms per verzoek. Effectief gratis.

De prestatie-impact concentreert zich in twee scenario's:

1. Cold start / verbindingsopbouwpieken: Game-lanceringen, seizoensevenementen, virale momenten — wanneer je origin duizenden nieuwe TLS-verbindingen per seconde verwerkt. Als je origin momenteel 50.000 ECDSA-handshakes/seconde afhandelt, verwacht dan ~20.000–25.000 ML-DSA-44-handshakes/seconde op equivalente hardware. Plan capaciteit dienovereenkomstig.

2. Kortlevende verbindingen: Als je architectuur een nieuwe TLS-verbinding per verzoek creëert (doe dat niet), betaalt elk verzoek de volledige handshake-kosten. Los dit op met connection pooling en persistente verbindingen voordat je migreert naar PQ-auth.

Bandbreedte-impact

De ~4,5 KB extra handshake-gegevens per nieuwe verbinding zijn verwaarloosbaar voor HTTP/2 of HTTP/3 multiplexed verbindingen. Voor WebSocket-gebaseerde gameprotocollen met langlevende verbindingen vindt de handshake één keer per verbindingslevensduur plaats — irrelevant voor bandbreedtebudgetten.

Best Practices voor PQ Game Backend Migratie

1. Schakel eerst PQ-encryptie in, daarna authenticatie. Als je nog geen post-quantum sleuteluitwisseling (X25519Kyber768) hebt ingeschakeld voor je origin-verbindingen, doe dat dan voordat je certificaten aanpakt. Het is een configuratiewijziging — geen nieuwe certificaten — en het beschermt onmiddellijk tegen harvest-now/decrypt-later aanvallen.

2. Implementeer ML-DSA-44, niet ML-DSA-87. Tenzij je geclassificeerde militaire systemen beschermt, biedt ML-DSA-44 comfortabele beveiligingsmarges op NIST Categorie 2. ML-DSA-87 verdubbelt ruwweg je handshake-overhead voor marginaal beveiligingsvoordeel dat je dreigingsmodel vrijwel zeker niet vereist.

3. Draai dual-stack tijdens de overgang — verwijder dan klassiek genadeloos. Implementeer zowel klassieke als PQ-certificaten parallel. Monitor minimaal twee weken. Bevestig nul klassieke fallback-verbindingen. Verwijder dan klassiek vertrouwen volledig. Het achterlaten van klassieke fallbacks is de meest voorkomende fout in PQ-migratie — het maakt je dure nieuwe certificaten veiligheidstheater.

4. Automatiseer sleutelrotatie vanaf dag één. Het 32-byte seed-formaat van ML-DSA maakt dit praktisch. Bouw certificaatrotatie in je implementatiepijplijn. Roteer per kwartaal — niet omdat de crypto verzwakt, maar omdat operationele sleutelhygiëne (gelekte credentials, vertrokken engineers, gecompromitteerde CI/CD) je werkelijke kwetsbaarheid is.

5. Profileer je verbindingswisselingssnelheid. Voer ss -s of equivalent uit op je origin servers om het aantal nieuwe verbindingen per seconde tijdens piek- en daluren te tellen. Vermenigvuldig met het handshake-overheadverschil (~1,5 ms CPU, ~4,5 KB bandbreedte). Dit geeft je een concreet capaciteitsplanningsgetal voor de migratie.

Wat Dit Betekent voor de Backend van Je Game

De post-quantum tijdlijn is niet langer academisch. NIST heeft ML-DSA gestandaardiseerd. Grote infrastructuurproviders implementeren het in productie. Overheidsmandaten versnellen de adoptie. De vraag is niet of je game backend PQ-authenticatie nodig heeft — het is wanneer je met de migratie begint.

Voor teams die hun eigen origin-infrastructuur beheren, is het werk reëel maar begrensd: genereer nieuwe certificaatketens, werk serverconfiguraties bij, wijzig vertrouwensopslag, test en verwijder klassieke fallbacks. Elke stap is een paar uur werk. Cumulatief is het een project van één tot twee weken voor een backend engineer die comfortabel is met TLS.

Als je die weken liever aan gameplay besteedt dan aan cryptografische infrastructuur, horizOn verzorgt TLS-terminatie, mTLS en certificaatbeheer als onderdeel van zijn backendplatform — zodat je functies kunt uitbrengen terwijl de PQ-migratie loopt als een configuratiewijziging in plaats van een meerweeks infrastructuurproject.

Begin vandaag. Voer de auditcommando's uit Stap 1 uit tegen je productie-origin. Controleer welk handtekeningalgoritme je certificaten gebruiken. Als het RSA of ECDSA is, voeg dan PQ-authenticatiemigratie toe aan je roadmap voor 2026–2027. De quantumcomputers die op de gegevens van je spelers afkomen, zullen niet wachten tot jij klaar bent.

---

Bron: Post-quantum authenticatie naar origins is nu ondersteund