Vad Google Clouds PQC-färdplan för 2029 innebär för företagskunder

Snabbt svar: Google Clouds färdplan efter kvantum, som först tillkännagavs den 25 mars 2026, är uppdelad i tre spår med olika deadlines: konfidentialitet och lagra-nu-dekryptera-senare-skydd som siktar på att vara slutfört i slutet av 2027, integritet och oavvislighet (digitala signaturer, certifikat, identitet) som siktar på att vara slutförda i slutet av 2028, och kryptografiska grunder (nyckelhantering, hårdvara, flexibilitet) som också siktar på att vara slutförda i slutet av 2028, med full beredskap senast 2029. Flera delar är redan live: Cloud KMS har nått allmän tillgänglighet för ML-KEM, ML-DSA och SLH-DSA, och Google Cloud API-slutpunkter och stödda lastbalanserare förhandlar redan om hybrid ML-KEM-nyckelutbyte. Det kundberoende som är viktigast: Google migrerar sin egen infrastruktur och hanterade tjänster, men TLS-konfiguration på kundsidan, kryptografi på applikationslagret och eventuella klientbibliotek som fortfarande är fästa vid klassiska algoritmer förblir kundens ansvar, samma delade ansvarsfördelning som behandlas i vår bredare guide för moln-PQC.

En färdplan med ett datum 2029 är lätt att läsa som "inte brådskande ännu". Den tolkningen missar poängen med en fasad färdplan: sekretessspåret stängs först, i slutet av 2027, särskilt eftersom risken "lagra-nu-dekryptera-senare" redan är aktiv idag. Den här guiden delar upp färdplanen i vad den faktiskt täcker, vad som är live nu och vad företagskunder behöver göra på sin egen sida oavsett Googles egen tidslinje.

Key Takeaways

• Färdplanen är uppdelad i tre spår: sekretess (slutet av 2027), integritet och oavvislighet (slutet av 2028) och kryptografiska grunder (slutet av 2028), med målsättningen att vara fullt beredskapsklar 2029.
• Cloud KMS har redan generellt stöd för ML-KEM, ML-DSA och SLH-DSA för kryptering och signeringsnycklar; Google Cloud API-slutpunkter och stödda lastbalanserare förhandlar redan om hybrid ML-KEM-nyckelutbyte.
• Google strävar efter Merkle Tree-certifikat, utvecklade tillsammans med branschpartners, som ett alternativ till att bädda in stora postkvantumsignaturer direkt i X.509-certifikat.
• Googles eget ansvar omfattar nätverkstrafik, globala gränssnitt, det interna ALTS-protokollet och underliggande hårdvara och operativsystem; kundkonfigurerade TLS-policyer, kryptografi på applikationslagret och klientbibliotek förblir kundens ansvar.
• Googles mål för slutförandet 2029 överensstämmer nu med Cloudflare och en reviderad, accelererad tidslinje från Microsoft, vilket gör 2029 till ett gemensamt branschriktmärke snarare än ett isolerat datum för en leverantör.

De tre spåren, och varför sekretessen stängs först

Google Clouds färdplan prioriterar medvetet konfidentialitet framför integritet, och resonemanget är viktigt för hur kunder bör prioritera sitt eget arbete. Risk "lagra-nu-dekryptera-senare", en motståndare som idag fångar krypterad trafik för att dekryptera när en kryptografiskt relevant kvantdator existerar, är redan aktiv, vilket är anledningen till att konfidentialitetsspåret, som omfattar nätverkskryptering och nyckelutbyte, har den tidigaste deadline: slutet av 2027. Integritet och oavvislighet, digitala signaturer, certifikat och autentiseringsmekanismer som förhindrar förfalskade identiteter eller manipulerad data, har en längre bana till slutet av 2028, vilket återspeglar både lägre omedelbar brådska (en förfalskad signatur kräver en aktiv attack idag, inte bara infångad data) och det genuint svårare tekniska problem som signaturmigrering representerar över ett certifikatekosystem. Grundläggande arbete, nyckelhanteringsbibliotek, hårdvarusäkerhetsmoduler, integration av externa nyckelhanterare och kryptografisk flexibilitet, löper också till slutet av 2028, eftersom det ligger till grund för båda de andra spåren snarare än att stå ensamt.

Det som redan finns live

Flera punkter i färdplanen är inte framtida åtaganden; de är levererade, allmänt tillgängliga funktioner från och med 2026:

• Moln-KMS: allmänt tillgängligt stöd för ML-KEM, ML-DSA och SLH-DSA för både krypterings- och signeringsnycklar, med underliggande implementeringar som underhålls som öppen källkod via Googles BoringCrypto- och Tink-bibliotek för granskningsbarhet.
• Google Cloud API-slutpunkter och lastbalanserare: google.com och *.googleapis.com, tillsammans med stödda applikations- och proxybelastningsutjämnare, förhandlar redan om hybrid ML-KEM-nyckelutbyte, inklusive X25519MLKEM768 för TLS 1.3.
• ALTS: Googles interna transportprotokoll för applikationslagret slutförde sin övergång till konfidentialitet efter kvantumsanvändning år 2025.
• Kvantsäker nyckelimport till Cloud KMS: målsatt för 2026 inom grundspåret.

Fortfarande framåt på den kortsiktiga färdplanen: Cloud VPN och sammankoppling (2026-2027), privat certifikatutfärdare genom certifikatutfärdartjänst (2027) och molnbaserad HSM och konfidentiell databehandling efter kvantstöd (2028).

Merkle Tree-certifikat: En annan metod för PKI

Ett strukturellt val i Googles färdplan är värt att förstå i sig självt: istället för att bädda in post-kvantumsignaturer direkt i det befintliga X.509-certifikatformatet, en metod som blåser upp certifikat- och kedjestorlekar avsevärt, utvecklar Google Merkle Tree-certifikat tillsammans med branschpartners som en alternativ certifikatarkitektur utformad kring post-kvantumbegränsningar från grunden, snarare än att eftermontera det klassiska formatet. Detta är fortfarande en framväxande, utvecklande metod snarare än en drop-in-ersättning för X.509 idag, och det förändrar inte vad kunderna behöver göra på sin egen certifikatinfrastruktur på kort sikt, men det signalerar att innovation i certifikatformat, inte bara algoritmsubstitution, är en del av hur de största moln- och CDN-operatörerna närmar sig signatursidan av denna övergång.

Vad som återstår kundens ansvar

Googles egen inramning av den delade ansvarsfördelningen är direkt: Google hanterar molnets säkerhet, inklusive nätverkstrafik, globala front-ends, ALTS och den underliggande hårdvaran och operativsystemen, och upprätthåller hårdvaruintegriteten genom kvantsäkra kiselfundament som Caliptra och OpenTitan. Kunderna ansvarar fortfarande för att konfigurera sina egna arbetsbelastningar för att faktiskt använda de post-kvantumfunktioner som Google gör tillgängliga, TLS-konfiguration på applikationslagret, klientbiblioteksversioner och all kryptografi som implementeras i kundens egen kod snarare än delegeras till en hanterad Google-tjänst. Detta är samma distinktion som behandlas i mer allmänna termer i vår guide om delat ansvar i molnet : en leverantör som migrerar sin egen infrastruktur migrerar inte automatiskt en kunds beroenden på applikationslagret.

Vad vi egentligen skulle rekommendera

Prioritera ditt eget arbete med sekretessspårning, TLS-konfiguration och nyckelutbyte, före signaturspårningsarbete, i enlighet med Googles egen sekvenseringslogik, eftersom exponering för att lagra-nu-dekryptera-senare är den mer närliggande risken. Bekräfta vilka Cloud KMS-nycklar i din miljö som redan använder ML-KEM eller ML-DSA kontra att fortfarande använda klassiska algoritmer, eftersom det faktum att funktionen är allmänt tillgänglig inte betyder att dina befintliga nycklar har flyttats till den automatiskt. Spåra Googles privata CA och Cloud HSM-milstolpar efter kvantum, specifikt om din arkitektur är beroende av någon av dem, eftersom dessa hamnar senare i färdplanen än API- och lastbalanseringsfunktionerna som redan finns.

Hur krypteringskonsulting kan hjälpa

Att veta vilka av dina Google Cloud KMS-nycklar, TLS-policyer för lastbalanserare och certifikatberoenden som redan är post-quantum-kompatibla, och vilka som fortfarande behöver åtgärdas från din sida, är precis det lagergap som CBOM Secure är byggt för att täcka, genom att kartlägga ditt molnkryptografiska fotavtryck mot vad Google Cloud har och ännu inte har migrerat.

Våra PQC-rådgivningstjänster bygger en kundsidesplan som är sekvenserad efter Google Clouds egen trespåriga tidslinje, så att ditt arbete med konfidentialitetsspårning hamnar före exponeringsfönstret "lagra nu, dekryptera senare" och ditt arbete med signaturspårning är klart innan Googles privata CA och certifikatmilstolpar når sina mål. Där certifikatutfärdande sträcker sig över Google Cloud tillsammans med andra miljöer hanterar CertSecure Manager klassiska, hybrid- och postkvantumcertifikat från ett enda policyplan.

En leverantörs tidslinje, inte en kunddeadline

Google Clouds färdplan visar när Googles egen infrastruktur kommer att vara redo för kvantumshantering. Den berättar inte när din applikation, din certifikatkedja eller din specifika Cloud KMS-nyckelkonfiguration kommer att vara det, eftersom det förblir kundsidans arbete oavsett hur snabbt Google agerar. Att läsa trespårssekvenseringen som prioriteringsvägledning, sekretess först, signaturer och grunder därefter, är det mest användbara sättet att översätta en leverantörsfärdplan till din egen migreringsplan.

Vanliga frågor om partihandel med mat och dryck

När tillkännagav Google Cloud sin post-kvantum-färdplan?

Google tillkännagav först det företagsomfattande målet för 2029 den 25 mars 2026, och den detaljerade tredelade färdplanen och sina egna milstolpar publicerades kort därefter.

Varför har sekretessspåret en tidigare deadline än signaturspåret?

Risk för att lagra-nu-avkryptera-senare-säkerhet mot krypterad nätverkstrafik är en aktiv, aktuell exponering, eftersom en angripare kan fånga trafiken nu och dekryptera den senare. Förfalskning av en signatur eller ett certifikat kräver en aktiv attack vid användningstillfället, vilket är en senare risk, vilket ger signaturspåret en längre bana fram till slutet av 2028.

Täcker Google Clouds PQC-migrering min applikation automatiskt?

Inte helt. Google migrerar sin egen hanterade infrastruktur, nätverkstrafik och tjänster, men kundkonfigurerade TLS-policyer, kryptografi på applikationslagret och klientbibliotek är fortfarande kundens ansvar att uppdatera och aktivera.

Vad är Merkle Tree-certifikat?

En alternativ certifikatarkitektur som Google utvecklar tillsammans med branschpartners, utformad kring postkvantumstorleks- och prestandabegränsningar från grunden snarare än att bädda in stora postkvantumsignaturer i det befintliga X.509-formatet. Det är en framväxande metod, inte en nuvarande drop-in-ersättning för X.509.

Vilka post-quantum-funktioner i Google Cloud är redan allmänt tillgängliga?

Stöd för Cloud KMS för ML-KEM, ML-DSA och SLH-DSA; hybrid ML-KEM-nyckelutbyte på Google Cloud API-slutpunkter och lastbalanserare som stöds; och post-kvantumkonfidentialitet för Googles interna ALTS-protokoll, färdigställt 2025.