Google’s 2029 PQC deadline changes cryptographic risk planning

At a glance

What this is: This is Keyfactor’s analysis of Google’s 2029 post-quantum migration horizon and the implication that cryptographic planning windows are already shrinking.

Why it matters: It matters because identity, signing, and trust systems across NHI, autonomous, and human programmes all depend on cryptography that must be inventoried, rotated, and eventually replaced without breaking operations.

By the numbers:

• 48% of organizations are not prepared to confront quantum threats.
• 91% lack a formal PQC migration roadmap according to the Trusted Computing Group.

👉 Read Keyfactor’s analysis of Google’s 2029 post-quantum migration horizon

Context

Post-quantum cryptography planning is the process of mapping where RSA, ECC, signatures, and related trust dependencies exist, then preparing systems to replace them without losing authentication or integrity. Google’s 2029 horizon matters because it shortens the practical timeline for crypto-agility across identity, software signing, and machine trust.

For IAM teams, this is not only a cryptography issue. Certificates, token signing, federation dependencies, workload identity, and service-to-service trust all depend on algorithms that will eventually need replacement, and brittle implementations turn that transition into operational debt.

Key questions

Q: How should security teams prepare identity systems for post-quantum cryptography?

A: Start with a full inventory of certificates, signatures, algorithms, and federation dependencies, then rank them by business criticality and data longevity. The goal is to know which identity and trust paths must change first, and whether they can accept new algorithms without redesign. Without that map, PQC becomes guesswork.

Q: Why do digital signatures matter more than encryption in PQC planning?

A: Digital signatures validate software, devices, federation, and workload trust, so failure affects the mechanism that proves something is genuine. Encryption loss is serious, but signature compromise can collapse trust across infrastructure. That is why signature systems and certificate chains should be prioritised early in migration planning.

Q: What breaks when cryptographic systems are not agile?

A: Systems that hardcode algorithms or bind trust to one certificate format become expensive and slow to replace. When post-quantum standards change, those environments cannot adapt cleanly, and migration turns into a multi-year operational project. In identity terms, brittle crypto creates trust debt that eventually has to be repaid.

Q: Who should own PQC readiness in an organisation?

A: Ownership should sit across security architecture, identity engineering, PKI, application teams, and infrastructure governance, because cryptographic dependencies cross all of them. If PQC is owned only by a cryptography specialist, the programme will miss the identity and operational dependencies that make migration succeed or fail.

Technical breakdown

Why digital signatures are the harder PQC problem than encryption

Encryption protects data at rest or in transit, but digital signatures protect trust itself. They validate software updates, certificate chains, device identity, federated authentication, and code integrity, and they are often far more embedded than bulk encryption. That makes them harder to inventory and much harder to replace. Google’s shift toward prioritising signatures and authentication reflects the fact that once signature trust collapses, the failure is systemic. The issue is not just confidentiality loss, but the breakdown of the mechanism that proves a system, certificate, or workload is legitimate.

Practical implication: inventory every signing dependency before focusing on data encryption.

What cryptographic agility actually means in identity systems

Cryptographic agility is the ability to swap algorithms, update trust anchors, and reissue certificates without redesigning applications or rebuilding infrastructure. In practice, that means key management, certificate issuance, application libraries, identity federation, and hardware dependencies must all support change. Systems that hardcode algorithms, embed assumptions in firmware, or tie identity workflows to one certificate format create migration bottlenecks. Agility is not a theoretical security property. It is an engineering condition that determines whether PQC becomes a controlled migration or a multi-year outage risk.

Practical implication: test whether identity and signing systems can change algorithms without code rewrites.

Why long-lived signatures create trust debt

Long-lived signature keys are especially dangerous because they anchor trust over extended periods and are often difficult to rotate quickly. If a future quantum adversary can forge or weaken them, the damage is not limited to one credential. It can affect software authenticity, device trust, and the integrity of signed artifacts across the enterprise. That creates what amounts to trust debt, where today’s convenience becomes tomorrow’s exposure. The problem grows when organisations lack a complete cryptographic inventory, because invisible dependencies cannot be prioritised or retired in time.

Practical implication: prioritise long-lived signing keys and certificate chains in migration sequencing.

NHI Mgmt Group analysis

Cryptographic agility is now an identity governance requirement, not a niche crypto concern. Identity programmes depend on certificates, signatures, federation, and workload trust far more than most migration plans admit. When those trust anchors cannot be replaced cleanly, IAM and NHI programmes inherit a future breakglass problem that no access review can solve later. Practitioners should treat algorithm mobility as part of identity architecture, not a postscript.

Signature trust is the real pressure point for machine identity, because it binds software, devices, and services into one trust fabric. Encryption can often be layered, but signature failure breaks verification itself, which is the control that underpins workload identity, certificate validation, and signed code. That means PQC readiness has direct consequences for NHI governance, especially where service identities depend on certificates or signed tokens. Teams should map trust dependencies by identity function, not by storage location.

48% of organisations still unprepared for quantum threats shows that the problem is not lack of awareness but lack of operational inventory. The gap is not abstract fear of a future event, it is the inability to answer where RSA, ECC, and long-lived signatures actually sit. Without that visibility, migration sequencing becomes guesswork. Practitioners should read this as a discovery and dependency management problem first.

Q-Day is becoming a planning horizon problem, not a single event problem. Google’s 2029 target, alongside existing 2031 and 2035 reference points, shows that readiness will be measured by migration capability rather than deadline awareness. The field should expect cryptographic transition to behave like a long governance programme with dependencies, exceptions, and rework. Teams that wait for certainty will already be behind.

Quantum readiness will expose which identity architectures were built for change and which were built for permanence. Systems that can reissue, rebind, and revalidate trust without downtime will absorb PQC transition far better than brittle stacks tied to one algorithm family. The broader implication is that identity architecture maturity now includes the ability to survive cryptographic substitution. Practitioners should assess crypto-agility as a resilience control.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• For the broader governance picture, read Ultimate Guide to NHIs , Key Research and Survey Results for the visibility, rotation, and offboarding baseline.

What this signals

PQC readiness will force identity teams to treat cryptographic inventory as part of normal governance, not a one-off audit exercise. The organisations that can trace certificates, signing keys, and federation dependencies will be the ones that can move on time without destabilising access paths.

Trust-chain substitution: the practical challenge is not choosing a new algorithm, but replacing every place where the old algorithm is silently embedded in authentication, signing, and workload trust. That means architecture teams need to plan for repeated reissuance and validation, not a single migration cutover.

For practitioners, the immediate signal is that crypto-agility should be measured like resilience. If identity, PKI, and workload systems cannot change algorithms without code or infrastructure redesign, they are already behind the transition curve.

For practitioners

• Inventory cryptographic dependencies across identity and trust paths Map where RSA, ECC, signatures, certificates, token issuers, and federation dependencies exist across applications, workloads, and device trust chains. Include software signing, workload identity, and external integrations so hidden dependencies do not block migration sequencing.
• Prioritise long-lived signing keys first Focus on code signing, certificate authorities, device trust anchors, and authentication signatures that persist for long periods. These are the dependencies most likely to create systemic trust failure if migration is delayed.
• Test algorithm substitution before deadlines force it Validate whether identity and application systems can change cryptographic algorithms without code rewrites, infrastructure replacement, or service interruption. If substitution requires redesign, the programme is not crypto-agile.
• Build PQC into identity governance roadmaps Treat PQC as part of certificate lifecycle, workload identity, and authentication governance planning, not as an isolated cryptography project. Align migration milestones with inventory, risk ranking, and change-management cycles.

Key takeaways

• Google’s 2029 horizon compresses the planning window for organisations that still depend on RSA and ECC to sign, authenticate, and trust systems.
• The readiness gap is already measurable, with major shares of organisations lacking PQC preparedness and formal migration roadmaps.
• Identity, PKI, and workload teams should build crypto-agility now, because brittle trust paths will be the part of the stack that slows or breaks migration later.

Key terms

• Post-quantum cryptography: Cryptographic algorithms designed to resist attacks from sufficiently capable quantum computers. In practice, PQC is a migration problem as much as a math problem because organisations must replace trust mechanisms embedded in certificates, signatures, and identity infrastructure without breaking operations.
• Cryptographic agility: The ability to change cryptographic algorithms, keys, and trust mechanisms without redesigning the underlying system. For identity programmes, this means certificate, signature, and federation layers can adapt to new standards while preserving authentication, workload trust, and service continuity.
• Digital signature trust: The assurance that a certificate, code artefact, device, or token was created by a legitimate issuer and has not been altered. In identity systems, signature trust is foundational because it validates software, federation, and machine identity before access is granted.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Keyfactor: Google just moved the Q-Day deadline to 2029 and what that means for you. Read the original.