TL;DR: Google’s internal move to a 2029 post-quantum migration horizon compresses planning runway for RSA and ECC-dependent systems, while Keyfactor cites a 48% readiness gap and 91% of organisations lacking a PQC roadmap. The real issue is cryptographic agility: infrastructure that cannot swap algorithms cleanly will turn future migration into a long, brittle recovery project.
NHIMG editorial — based on content published by Keyfactor: Google just moved the Q-Day deadline to 2029 and what that means for you
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Prioritise long-lived signing keys first Focus on code signing, certificate authorities, device trust anchors, and authentication signatures that persist for long periods.
- 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.
What's in the full article
Keyfactor's full article covers the operational detail this post intentionally leaves for the source:
- The specific quantum-readiness survey context behind the 48% and 91% findings
- Keyfactor's breakdown of why cryptographic agility matters more than one algorithm choice
- The article's practical starting-point checklist for inventorying certificates and dependencies
- The full discussion of regulatory timelines and what they mean for planning priorities
👉 Read Keyfactor’s analysis of Google’s 2029 post-quantum migration horizon →
PQC migration by 2029: what identity and security teams need?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Google’s 2029 PQC deadline changes cryptographic risk planning