Bij moderne websitebeveiliging denken veel organisaties vooral aan HTTPS, sterke wachtwoorden en up-to-date software. Maar onder de oppervlakte verandert er iets veel fundamentelers: de opkomst van quantumcomputing zet de cryptografie waarop internetverkeer vandaag vertrouwt onder druk. Dat betekent niet dat je website morgen ineens onveilig is, maar wel dat je nu al moet nadenken over een toekomst waarin huidige beveiligingsstandaarden niet meer voldoende zijn. Wie zijn hosting, infrastructuur en codebase slim inricht, kan die overgang beheersbaar maken.
Wat is post-quantum cryptografie en waarom is het relevant voor websecurity?
Post-quantum cryptografie, vaak afgekort als PQC, is cryptografie die ontworpen is om veilig te blijven, zelfs als aanvallers beschikken over een krachtige quantumcomputer. Het belangrijkste probleem zit niet in alle vormen van encryptie, maar vooral in de klassieke vormen van public-key cryptografie: algoritmes zoals RSA en elliptische-curve cryptografie (ECC). Die vormen de basis voor onder meer HTTPS, digitale certificaten, code signing en veilige sleuteluitwisseling.
Waarom dit zo belangrijk is, wordt duidelijk als je kijkt naar Shor’s algorithm. Een voldoende krachtige quantumcomputer kan daarmee bepaalde wiskundige problemen veel sneller oplossen dan klassieke computers. Juist die problemen vormen de basis van RSA en ECC. NIST beschrijft deze dreiging expliciet op de PQC-projectpagina: https://www.nist.gov/pqcrypto
Voor websecurity heeft dit grote gevolgen. Het betekent namelijk dat systemen die vandaag veilig lijken, in de toekomst ontsleuteld of vervalst kunnen worden als hun beveiliging volledig leunt op klassieke public-key cryptografie. Dat raakt niet alleen websites, maar ook:
- TLS/SSL-certificaten
- server-authenticatie
- sleuteluitwisseling in HTTPS
- code signing van software en updates
- VPN’s en identity-systemen
- e-mailbeveiliging en PKI
Belangrijk is wel dat PQC geen “paniekverhaal” is. De boodschap is eerder: de migratie kost tijd, dus je moet er op tijd mee beginnen. Organisaties zoals CISA, NIST, NSA en NCSC benadrukken dat de overgang een meerjarig traject is, niet iets wat je in een paar weken even ombouwt. Zie bijvoorbeeld de CISA/NIST/NSA factsheet: https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography
Een belangrijk concept hierbij is harvest now, decrypt later. Aanvallers kunnen vandaag al versleuteld verkeer onderscheppen en opslaan, om het later te ontsleutelen wanneer quantumaanvallen praktisch worden. Dat is vooral relevant voor data met een lange houdbaarheid: medische gegevens, contracten, klanthistorie, financiële informatie, intellectueel eigendom en interne communicatie. De NCSC-UK whitepaper over post-quantum voorbereiding beschrijft dit risico nadrukkelijk: https://www.ncsc.gov.uk/whitepaper/next-steps-preparing-for-post-quantum-cryptography
Welke digitale systemen lopen het grootste risico bij quantumcomputing?
Niet elk systeem wordt even hard geraakt door quantumcomputing. Het grootste risico zit in componenten die afhankelijk zijn van asymmetrische cryptografie. Denk aan plaatsen waar je een publieke sleutel gebruikt om te verifiëren, uit te wisselen of te ondertekenen.
De belangrijkste risicogebieden zijn:
- TLS/SSL en HTTPS
- Digitale certificaten en PKI
- Code signing
- Authenticatie- en identitysystemen
- VPN’s en secure tunnels
- Firmware- en updateprocessen
- Langdurige opslag van gevoelige data
- Back-ups en archieven met lange bewaartermijn
Voor websites is TLS de meest directe zorg. TLS gebruikt public-key mechanismen voor authenticatie en sleuteluitwisseling. Juist die onderdelen zijn kwetsbaar in een quantumscenario. De cryptografie achter het versleutelde kanaal is dus niet “stuk”, maar de bouwstenen die het kanaal opzetten zijn dat op termijn wel.
Symmetrische encryptie, zoals AES, is minder hard getroffen. Quantumcomputers bieden daar vooral een theoretische versnelling via Grover’s algorithm, wat in de praktijk vaak kan worden gecompenseerd met grotere sleutelgroottes, zoals AES-256. De NSA en NIST wijzen daar ook op in hun richtlijnen en FAQ’s:
- NIST: https://www.nist.gov/pqcrypto
- NSA CNSA 2.0 FAQ: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSACNSA2.0FAQ.PDF
Dat betekent: databases die met sterke symmetrische encryptie zijn beveiligd, zijn niet per definitie kansloos. Maar de zwakke plek zit vaak in de sleutelketen, certificaten, authenticatie en de manier waarop sleutels worden beheerd of uitgewisseld.
Voor organisaties met data die nog jaren relevant blijft, is dat een serieuze overweging. Wat vandaag nog “veilig genoeg” lijkt, kan over tien jaar een probleem zijn als de gegevens retrospectief ontsleuteld kunnen worden.
De belangrijkste PQC-algoritmes en hun praktische toepassingen
De overgang naar PQC is inmiddels niet meer alleen theoretisch. NIST heeft de eerste standaarden gepubliceerd voor post-quantum cryptografie. Dat is een belangrijke mijlpaal, omdat het laat zien dat de sector niet wacht op één perfecte oplossing, maar al een concrete richting heeft gekozen.
De eerste drie NIST-standaarden zijn:
-
ML-KEM voor key establishment
Gebaseerd op Kyber
FIPS 203: https://csrc.nist.gov/pubs/fips/203/final -
ML-DSA voor digitale handtekeningen
Gebaseerd op Dilithium
FIPS 204: https://csrc.nist.gov/pubs/fips/204/final -
SLH-DSA voor stateless hash-based signatures
Gebaseerd op SPHINCS+
FIPS 205: https://csrc.nist.gov/pubs/fips/205/final
Waarom zijn juist deze algoritmes belangrijk? Omdat ze de kernfuncties vervangen waar huidige publieke sleutelcryptografie in uitblinkt: sleuteluitwisseling en digitale handtekeningen. Voor webinfrastructuur betekent dat uiteindelijk nieuwe manieren om:
- veilige sessies op te zetten
- certificaten te ondertekenen
- software te verifiëren
- identiteiten te controleren
Er zijn ook aanvullende algoritmen en vervolgstappen in ontwikkeling. NIST heeft laten zien dat crypto-agility en diversiteit belangrijk zijn, zodat niet alles van één cryptografische familie afhangt. Daar hoort ook vervolgonderzoek naar onder meer Falcon-gebaseerde technieken bij: https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms
In de praktijk wordt vaak gewerkt met een hybride aanpak. Daarbij combineer je een klassieke methode met een post-quantum methode. Dat is handig als tussenstap, omdat het de risico’s van volledige overstap verlaagt. Leveranciers zoals Cloudflare en Google hebben hier al jaren experimenten mee gedaan:
- Cloudflare: https://blog.cloudflare.com/post-quantum-for-all/
- Google Security Blog: https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html
Voor organisaties is dit belangrijk, omdat het migratiepad dan niet “alles of niets” hoeft te zijn.
Impact op SSL/TLS, certificaten en website-architectuur
Als je kijkt naar websites, is TLS het eerste onderdeel dat je serieus moet meenemen in je PQC-strategie. HTTPS blijft essentieel, maar de manier waarop een verbinding tot stand komt, moet op termijn veranderen.
TLS gebruikt public-key cryptografie voor twee cruciale zaken:
- authenticatie via certificaten
- sleuteluitwisseling voor het opzetten van de beveiligde sessie
Dat betekent dat juist de handshake, certificaatketen en trust chain de punten zijn waar quantumrisico’s zich het eerst vertalen naar praktische impact.
Een belangrijk effect van PQC is dat sommige sleutels, certificaten en handtekeningen groter worden. De NIST-standaarden en praktijkervaringen van partijen als Cloudflare laten zien dat post-quantum artefacten vaak meer bytes verbruiken dan klassieke RSA/ECC-varianten. Zie de FIPS-documenten hierboven en Cloudflare’s toelichting: https://blog.cloudflare.com/post-quantum-for-all/
Dat heeft gevolgen voor:
- handshake-grootte
- latency
- netwerkverkeer
- CPU- en geheugengebruik
- certificaatopslag
- CDN- en edge-afhandeling
Voor website-architectuur betekent dit dat je verder moet kijken dan alleen “een certificaat installeren”. Je moet je hele keten bekijken:
- welke webserver gebruik je?
- welke load balancer?
- welk certificaatbeheer?
- welke CDN?
- welke identity provider?
- welke clientcompatibiliteit moet je ondersteunen?
RDS-Online kan hier bijvoorbeeld goed aansluiten vanuit bestaande websitebeveiliging: SSL-certificaten, veilige hosting, WAF-beleid en een sterke basisinrichting blijven cruciaal. PQC is daar geen vervanging van, maar een volgende laag op de bestaande beveiligingsbasis.
De realiteit is: HTTPS verdwijnt niet. Maar de cryptografische bouwstenen onder HTTPS worden wel vernieuwd. Organisaties die nu al nadenken over crypto-agility — dus het vermogen om algoritmes uit te wisselen zonder grote herbouw — staan straks veel sterker.
Hoe je hosting, databases en codebases quantum-bestendig voorbereidt
De migratie naar PQC is niet alleen een taak voor securityteams. Het is ook een hosting-, development- en operationsvraagstuk. In de praktijk moet je kijken naar de hele stack: van serverconfiguratie tot database-verbindingen en deployment pipelines.
Een goede voorbereiding begint met inventarisatie:
- waar gebruik je RSA of ECC?
- waar zitten certificaten?
- welke libraries gebruiken cryptografie?
- welke services regelen authenticatie?
- welke back-ups bevatten langgevoelige data?
- welke systemen zijn afhankelijk van leveranciers of managed services?
CISA, NIST en NSA adviseren expliciet om cryptografie in kaart te brengen voordat je migreert: https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography
Voor hostingomgevingen betekent dit onder meer:
- controleer TLS-instellingen op webservers en load balancers
- inventariseer certificaatuitgifte en -vernieuwing
- bekijk of je CDN of edge provider PQC- of hybride support test
- controleer VPN’s, bastions en admin-toegang
- evalueer identity- en secrets-management
- kijk naar backupbeveiliging en bewaartermijnen
Voor databases geldt dat de grootste risico’s vaak niet in de data zelf zitten, maar in key management en toegangspaden. Data-at-rest die goed met symmetrische encryptie is beveiligd, blijft relatief sterk. Maar als de toegangscontrole, sleuteluitwisseling of certificaatgebaseerde toegang kwetsbaar is, is alsnog het geheel zwak.
Voor codebases en software supply chain is het net zo relevant. Denk aan:
- code signing
- build pipelines
- artifact repositories
- firmware updates
- release signing
- package verification
Als je software kunt vervangen, moet je het ook kunnen verifiëren. Juist dat verifiëren steunt nu nog vaak op klassieke handtekeningen. De NSA CNSA 2.0 FAQ en NIST PQC-pagina maken duidelijk dat dit onderdeel van de bredere migratie is.
Een praktische vuistregel: als iets vandaag een certificaat, sleutel, handtekening of trust chain gebruikt, hoort het in je PQC-inventaris.
Performance, schaalbaarheid en duurzaamheidsimpact van PQC
Een vaak onderschat aspect van post-quantum cryptografie is de impact op performance en infrastructuur. Veel PQC-algoritmes gebruiken grotere sleutels, grotere handtekeningen of grotere ciphertexts. Dat heeft gevolgen voor de hoeveelheid data die over het netwerk gaat en voor de rekencapaciteit op servers en clients.
De belangrijkste effecten zijn:
- meer bandbreedtegebruik
- mogelijk hogere latency bij handshakes
- extra geheugenverbruik
- soms meer CPU-belasting
- grotere certificaat- of handshake-objecten
Cloudflare heeft in de praktijk laten zien dat post-quantum TLS werkbaar is, maar dat de overhead en implementatiekeuzes wel degelijk invloed hebben op performance: https://blog.cloudflare.com/post-quantum-for-all/
Voor hosting betekent dit dat je niet alleen moet vragen: “Is het veilig?”, maar ook: “Wat doet dit met schaalbaarheid?”
Dat is ook waar duurzaamheid in beeld komt. Meer bytes en extra cryptografische verwerking kunnen leiden tot hoger energieverbruik, vooral op grote schaal. Er is geen universeel getal dat je één-op-één op elke omgeving kunt plakken, omdat het afhangt van algoritme, implementatie en workload. Maar het is wél terecht om duurzaamheid mee te nemen in je architectuurkeuzes.
Daar zit ook meteen een voordeel: een goed ontworpen migratie voorkomt verspilling. Organisaties die cryptografie goed inventariseren en zorgvuldig migreren, vermijden ad-hoc fixes, dubbele implementaties en onnodige herbouw. Dat is niet alleen beter voor security, maar ook voor efficiëntie en onderhoudskosten.
Voor organisaties die waarde hechten aan duurzame infrastructuur is dit een interessante invalshoek: toekomstbestendige security hoort samen te gaan met slim resourcegebruik.
Stappenplan voor een gefaseerde migratie naar post-quantum beveiliging
De beste migratie naar PQC is bijna nooit een big-bang-aanpak. In de praktijk werkt een gefaseerde route veel beter. Dat sluit ook aan bij de aanbevelingen van NCSC, CISA en NIST.
Een praktische aanpak ziet er zo uit:
1. Maak een cryptografische inventaris
Breng in kaart waar cryptografie wordt gebruikt in je omgeving. Denk aan:
- TLS-certificaten
- VPN’s
- SSH-toegang
- API-authenticatie
- code signing
- back-upbeveiliging
- database-verbindingen
- identity services
- hardware security modules
2. Classificeer data op bewaartermijn en gevoeligheid
Niet alle data is even urgent. Kijk vooral naar gegevens die lang vertrouwelijk moeten blijven. Juist daar speelt het harvest-now-decrypt-later-risico.
3. Breng leveranciers en afhankelijkheden in kaart
De migratie hangt niet alleen af van je eigen code, maar ook van:
- hostingprovider
- CDN
- load balancer
- certificate authority
- cloudomgeving
- managed database
- IAM/IdP
- back-updiensten
4. Test hybride oplossingen
Begin in staging, interne services of niet-kritische workloads. Hybride key exchange is een logische tussenstap omdat het klassieke en post-quantum mechanismen combineert.
5. Meet performance
Benchmark latency, CPU, geheugen en netwerkverkeer. Kleine verschillen in handshakegedrag kunnen op schaal groot worden.
6. Stel migratiebeleid op
Bepaal welke systemen als eerste over moeten. Vaak zijn dat systemen met:
- lange vertrouwelijkheid
- publieke exposure
- veel verkeer
- hoge compliance-eisen
7. Bouw crypto-agility in
Zorg dat algoritmes, libraries en certificaten vervangbaar zijn zonder grote herbouw. Dat scheelt toekomstige kosten en risico’s.
8. Houd toezicht op standaarden en leveranciers
PQC ontwikkelt zich snel. Blijf volgen wat NIST, NCSC, CISA en je cloud- en hostingpartners adviseren.
De kern van dit stappenplan is eenvoudig: wacht niet tot de technologie “volwassen genoeg” lijkt, maar organiseer nu al je overgangsvermogen.
Veelgemaakte fouten en een checklist voor de eerste audit
Bij PQC-migratie maken organisaties vaak dezelfde denkfouten. De belangrijkste:
1. Denken dat het alleen om HTTPS gaat
TLS is belangrijk, maar niet het enige. Ook code signing, back-ups, authenticatie en interne systemen tellen mee.
2. Aannemen dat symmetrische encryptie het grootste probleem is
Dat is meestal niet zo. De grootste directe quantumdreiging zit in public-key cryptografie zoals RSA en ECC.
3. Geen cryptografische inventaris maken
Zonder inventaris weet je niet waar de risico’s zitten. Dan wordt migratie reactief in plaats van planmatig.
4. Leveranciers vergeten
Veel organisaties onderschatten hoe afhankelijk ze zijn van CDN’s, cloudservices, certificaatbeheer en managed tooling.
5. Performance niet testen
PQC kan grotere artefacten en extra overhead geven. Test dus in realistische omstandigheden.
6. Te laat beginnen met beleid en governance
PQC is geen losse technische patch, maar een strategisch traject. Dat vraagt om eigenaarschap, planning en budget.
Voor de eerste audit kun je deze checklist gebruiken:
- Waar gebruiken we RSA, ECC of andere klassieke public-key cryptografie?
- Welke certificaten staan live, en hoe worden ze beheerd?
- Welke systemen moeten data 5+ jaar vertrouwelijk houden?
- Welke data staat in back-ups met lange bewaartermijn?
- Welke libraries en frameworks gebruiken cryptografie?
- Welke leveranciers bieden al hybride of PQC-testopties?
- Wat is de impact op latency, throughput en resourcegebruik?
- Is onze hostingstack voorbereid op snelle algoritmewissels?
- Hebben we MFA, sterke wachtwoorden, toegangsbeperkingen en een WAF goed ingericht?
- Zijn software, plugins en infrastructuur up-to-date?
Voor organisaties zoals RDS-Online past hier een sterke basisfilosofie in: veilige hosting, actuele securitymaatregelen, meerdere back-ups, betrouwbare infrastructuur en aandacht voor performance blijven de kern. PQC voegt daar een toekomstlaag aan toe, waarbij het belangrijk is om nu al te inventariseren welke systemen later kwetsbaar kunnen worden.
Conclusie
Post-quantum cryptografie is geen abstract toekomstthema meer, maar een concrete voorbereiding op een fundamentele verschuiving in webbeveiliging. De eerste standaarden zijn gepubliceerd, de risico’s voor RSA en ECC zijn helder, en de noodzaak van een meerjarige migratie is breed erkend door securityautoriteiten. Voor websites en hostingomgevingen betekent dit dat je nu al moet kijken naar certificaten, TLS, sleutelbeheer, code signing, databases, leveranciers en performance.
De organisaties die het beste voorbereid zijn, zijn niet per se degene die het snelst volledig overstappen. Het zijn de organisaties die hun cryptografie in kaart brengen, afhankelijkheden begrijpen en een flexibele migratiestrategie opbouwen. Wie vandaag begint met inventariseren, testen en plannen, voorkomt dat quantumveiligheid later een stressvolle noodoperatie wordt.