Post-quantum cryptografie en de impact op je dagelijkse security

Veel teams zien post-quantum cryptografie (PQC) als iets voor later, wanneer de standaarden definitief zijn. In de praktijk wordt je risicoprofiel nu al bepaald door keuzes die je de afgelopen tien jaar hebt gemaakt: hoe lang je netwerkverkeer bewaart, waar je TLS beëindigt, welke platforms je identity-laag beheren en hoe je digitale handtekeningen op lange termijn valideert.

PQC is geen eenmalige upgrade die je plant en afrondt. De invoering zal gefaseerd en ongelijk verlopen. Het begint bij wijzigingen in de cryptografische bouwstenen van protocollen die je vandaag al gebruikt. Daarna werkt het door in certificaten, platforms en je operationele processen. Wil je eerst scherp krijgen wat er verandert op het niveau van algoritmes en protocollen, dan is het zinvol om eerst dit artikel te lezen.

In deze blog koppelen we PQC aan dagelijkse securitymaatregelen. Zo zie je waar veranderingen het eerst zichtbaar worden, waar ze op de achtergrond plaatsvinden en waar je er op termijn niet meer omheen kunt.

1. Beveiligd webverkeer en TLS: de handshake verandert als eerste

Als mensen het hebben over “web encryptie”, bedoelen ze meestal HTTPS. In de praktijk betekent dat dat de eerste plek waar PQC zichtbaar wordt, de TLS-handshake is. Zelfs wanneer het dataverkeer zelf wordt beschermd met symmetrische encryptie, zijn de sessiesleutels en authenticatie afhankelijk van public-keymechanismen die naar verwachting door kwantumcomputers te breken zijn.

Wat verandert

Het eerste patroon dat je ziet is hybride key exchange. Je houdt een klassieke key exchange voor compatibiliteit en voegt daarnaast een post-quantum key establishment toe. Vervolgens combineer je de resultaten tot de sessiesleutels. Dit verkleint de exposure voor 'harvest now, decrypt later', zonder dat je een harde cutover op één dag nodig hebt. De IETF is al bezig met standaardisatie van hybride key exchange in TLS 1.3.

Aan de rand van het internet zie je dit nu al terug in grootschalige deployments. Cloudflare heeft bijvoorbeeld gepubliceerd hoe het hybride post-quantum key agreement heeft uitgerold voor verbindingen die zij afhandelen, inclusief wat zij beschrijven als een mijlpaal waarbij tegen eind oktober 2025 een meerderheid van het door mensen geïnitieerde verkeer hiermee werd afgehandeld.

Wat hetzelfde blijft

Voor eindgebruikers verandert er niets zichtbaar. Browsers blijven het slotje tonen. Applicaties openen TLS-sessies zoals ze dat altijd deden. De impact zit vooral in operations: libraries, endpoints en middleboxes moeten nieuwe key share-formaten ondersteunen, grotere handshake-berichten verwerken en omgaan met nieuwe failure modes.

Waar teams op moeten letten

• Handshake-grootte en netwerkgedrag: Grotere handshakes kunnen fragmentatiepatronen veranderen en kwetsbare aannames blootleggen in firewalls, TLS-inspectie en legacy proxies.
• Readiness van libraries en platforms: PQC-support komt meestal via updates van cryptografische libraries en platformen. Het integratiepunt zit vaak in de TLS-stack, niet in de applicatiecode.
• Afstemming en beleid: Hybride is niet simpelweg “aanzetten”. Je hebt duidelijke regels nodig over wanneer je het aanbiedt, wanneer je het verplicht stelt en hoe je coverage meet. rules about when it is offered, when it is required, and how you measure coverage.

2. Messaging en e-mail: bescherming van langdurige vertrouwelijkheid en authenticiteit

End-to-end-versleutelde messaging is een logische kandidaat voor vroege PQC-adoptie, omdat het threat model duidelijk is: onderschept verkeer kan worden opgeslagen om later te ontsleutelen als key establishment niet post-quantum veilig is.

Messaging

Apple’s PQ3 is een goed voorbeeld van hoe “achter de schermen” er op schaal uitziet. Apple beschrijft PQ3 als een post-quantum upgrade voor het end-to-endprotocol van iMessage, bedoeld om de drempel te verhogen tegen toekomstige aanvallers met quantumcapaciteiten, zonder dat gebruikers iets hoeven te veranderen in hun workflow.

Voor de meeste organisaties is het belangrijkste punt niet of je iMessage gebruikt. Het punt is dat grote platforms post-quantum key agreement en doorlopende re-keying nu al behandelen als iets dat je gefaseerd, op schaal en via software-updates kunt uitrollen.

E-mail en encryptie op bestandsniveau

Encryptie en signing in e-mail bewegen meestal langzamer, door interoperabiliteit en de traagheid van het ecosysteem. Toch is er veel activiteit in standaarden.

De IETF heeft een OpenPGP-draft waarin post-quantum-extensies worden gedefinieerd met hybride constructies. Daarbij worden ML-KEM en ML-DSA gecombineerd met klassieke algoritmes voor compatibiliteit. Dit is relevant voor langdurige vertrouwelijkheid en voor handtekeningen die jaren later nog geldig moeten zijn, zoals in juridische archieven, audit-artefacten en software provenance.

Voor S/MIME en CMS-achtige signing beschrijft het Open Quantum Safe-project praktische post-quantum en hybride signing-workflows, gebaseerd op OpenSSL-provider-aanpakken.

Waar teams op moeten letten

• Levensduur van signature-validatie: Als je signatures op lange termijn moet kunnen valideren, zijn de algoritmekeuzes en certificate chains net zo relevant als encryptie.
• Diversiteit in clients: Messaging-apps updaten snel. E-mailclients, gateways en DLP-stacks vaak niet.
• Beleid en UX-beperkingen: Gebruikers accepteren geen frictie. Dat duwt teams richting hybride en ‘stille’ upgrades.

3. Identity-systemen en certificaten: PQC verandert de trust-laag

Identity, authenticatie en autorisatie draaien in grote mate om certificaten: TLS-serveridentiteit, device identity, gebruikerscertificaten, smartcards, code signing, S/MIME, VPN-authenticatie en meer.

PQC raakt dit domein op twee manieren:

1. De sleutels in certificaten veranderen met nieuwe public keys en nieuwe signature-algoritmes.
2. De trust anchors en uitgifteprocessen veranderen, waaronder hoe CAs ondertekenen, hoe clients valideren en hoe revocation en vernieuwing werken.

Binnen de IETF wordt actief gewerkt aan specificaties voor het opnemen van post-quantum signatures, zoals Dilithium, in X.509-artefacten. Ook binnen het CA/Browser Forum lopen discussies en werkgroepen rond S/MIME en bredere voorbereidingen op post-quantum.

Identity-systemen zullen waarschijnlijk het traagst bewegen in de adoptie van PQC. Certificaten liggen onder TLS, device identity, user authenticatie en signing. Ze zijn gekoppeld aan trust stores, geldigheidsduur van certificaten, hardware-afhankelijkheden en interoperabiliteit met derde partijen.

4. De verandering die je wél gaat merken: integratie, performance en compatibiliteit

PQC is voor eindgebruikers meestal onzichtbaar, maar niet voor engineering en security operations.

Integratiepunten waar je mee te maken krijgt

• Cryptografische libraries en platform stacks: Denk aan TLS-libraries, SSH-stacks, VPN-implementaties en signing tooling.
• Key management en HSM’s: Key generation, opslag, signing-API’s en support voor nieuwe algorithm identifiers.
• Intermediairs: Load balancers, CDN’s, TLS-inspectie, WAF’s en monitoring tooling die handshakes of certificaten parseert.

Performance en sizing in de praktijk

PQC verandert vaak berichtgroottes en CPU-profielen. In veel omgevingen zit het eerste effect niet in pure throughput, maar in handshake-gedrag en memory pressure in hot paths. Daarom richten grootschalige deployments zich eerst op hybride key establishment, terwijl signatures en veranderingen in het certificaat-ecosysteem voorzichtiger volgen.

Standaarden bewegen nog, ze zijn niet af

De eerste PQC-standaarden van NIST zijn gepubliceerd als FIPS voor key establishment en signatures. Daarmee verschuift PQC van “pilot” naar planning op het niveau van inkoop en compliance.

NIST heeft in maart 2025 ook HQC geselecteerd als backup post-quantum encryptie-algoritme, expliciet om te diversifiëren voor het geval er later zwakheden worden gevonden in de primaire aanpak. Voor architecten is dit een nuttige reminder: algorithm agility is geen theoretische eis. Het is hoe je voorkomt dat je jezelf vastzet in een keuze waar je later moeilijk van afkomt.

5. PQC vertalen naar jouw omgeving

Als je PQC wilt koppelen aan dagelijkse systemen, begin dan met het indelen van je omgeving in deze drie categorieën:

1. Web- en API-verkeer (TLS): Internet-facing services, partner APIs, and internal service mesh.
2. Communicatie tussen mensen: Messaging, e-mail, document signing en secure collaboration.
3. Identity en trust: Certificaten, device identity, code signing, VPN-authenticatie en alles wat gekoppeld is aan PKI.

Breng daarna in kaart wat snel hybride kan adopteren, wat afhankelijk is van derde partijen en wat te maken heeft met lange validatie-eisen of dataretentie.

Praat met een PQC-specialist

Als je wilt begrijpen hoe PQC je dagelijkse security in jouw omgeving beïnvloedt, helpt het om dit door te spreken met iemand die in de praktijk met PQC werkt. Neem contact op om te bespreken waar PQC waarschijnlijk als eerste in je stack zichtbaar wordt, welke afhankelijkheden adoptie vertragen en hoe je een realistisch plan opbouwt dat past bij je risicoprofiel en je tijdlijnen.