Notifications
Clear all
Topic starter
25/06/2026 12:00 am
TL;DR: Quantum computing threatens current public key cryptography, and attackers can already preserve encrypted data for future decryption, according to SSH Communications Security. Long-lived systems, unmanaged keys, and slow migration cycles make cryptographic inventory and prioritisation an identity and access problem, not just a standards exercise.
NHIMG editorial — based on content published by SSH Communications Security: quantum-safe migration, cryptographic visibility, and PQC readiness
By the numbers:
- According to some, Q-day can be as early as 2027, or it could also take 20 years.
Questions worth separating out
Q: How should security teams prioritise post-quantum migration?
A: Start with the identities, certificates, and systems that protect long-lived data or anchor trust for other systems.
Q: Why do unmanaged keys make quantum migration harder?
A: Unmanaged keys and certificates hide the exact trust points that depend on vulnerable cryptography.
Q: When should organisations treat encrypted data as quantum-sensitive?
A: When the data must remain confidential beyond the likely lifetime of current public key cryptography.
Practitioner guidance
- Inventory cryptographic dependencies across identity paths Map where certificates, keys, host identities, SSH algorithms, and firmware signatures support authentication or trust decisions.
- Prioritise data by confidentiality lifespan Classify information by how long it must remain secret, then place long-lived records and industrial data ahead of short-retention assets in your PQC roadmap.
- Sequence migration by trust criticality Start with the identities and systems that anchor access, session setup, and code validation.
What's in the full article
SSH Communications Security's full article covers the operational detail this post intentionally leaves for the source:
- Agentless discovery workflow for user keys, host keys, and SSH server algorithms
- Risk visibility output that helps teams separate unmanaged assets from known dependencies
- Migration support detail for organisations planning quantum-safe remediation across legacy environments
- Compliance-oriented documentation output for audit and programme governance
👉 Read SSH Communications Security's analysis of quantum-safe migration and cryptographic risk →
Post-quantum migration: what IAM and security teams need to map now?
Explore further
25/06/2026 8:48 am
Quantum readiness is now an identity governance problem, not just a cryptography problem. Public key systems sit inside certificates, device authentication, session setup, and firmware validation, which means the trust layer for IAM and OT can fail together. Once those trust anchors become breakable, organisations are not just changing algorithms. They are changing how identities prove legitimacy across the estate. The implication is that quantum migration belongs in identity programme planning, not in a standalone crypto backlog.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: Who should own quantum migration in the enterprise?
A: Ownership should sit across identity, security architecture, infrastructure, and operational teams because the problem spans authentication, certificates, device trust, and legacy systems. A single team can coordinate the roadmap, but the migration itself crosses programme boundaries and requires shared accountability.
👉 Read our full editorial: Quantum-safe migration starts with cryptographic inventory and risk
