Organizations use encryption to protect information throughout its lifecycle. For some information, that protection needs to last a long time. A research archive, a patient record or a strategic business plan might remain sensitive for fifteen or twenty years, even as the systems that store and process it change.
Post-quantum cryptography introduces another consideration into that lifecycle. A sufficiently capable quantum computer could compromise widely used public-key mechanisms that establish encryption keys and verify digital signatures. An adversary could collect encrypted information today and attempt to decrypt it when the underlying protection becomes vulnerable. This is the “harvest now, decrypt later” risk, and it makes the required confidentiality lifetime of data an important part of migration planning. NIST’s PQC overview
The timing of that capability remains uncertain, but organizations already have a transition horizon to work toward. NIST identifies 2035 as the target for phasing quantum-vulnerable algorithms out of its standards, with higher-risk systems moving earlier. Discovery, application changes, supplier coordination and testing will take time, so the preparation needs to begin while current protections are still effective. NIST’s transition guidance
For a security team, the challenge is connecting this cryptographic transition to the environment it actually operates. Sensitive data moves between databases, applications, analytics platforms and external providers. Different teams own the identities, keys, certificates and services involved. To decide where migration should begin, the organization needs to understand those relationships and the consequences of a protection failure.
Cyera provides data and identity insights, risk prioritization and reporting to support PQC readiness assessments and migration planning. These findings inform the broader assessment alongside business requirements and cryptographic evidence from cloud services, KMS, PKI and discovery tools, helping teams focus on the data and workloads that matter most. Engineering teams then validate which cryptographic mechanisms need to change and how to implement those changes.
Start with the data and its useful life
Before deciding how to protect information for the next fifteen years, it is worth establishing which information needs to remain in the environment at all. Organizations accumulate exports, development datasets, old backups and copies created for projects that have already ended. Each additional copy creates another location where access, retention and protection need to be managed.
Discovery and classification provide the starting point for making those decisions. Cyera helps identify sensitive data and its exposure, while its data-minimization capabilities surface unnecessary data and retention issues. Data owners can use that information to remove redundant, obsolete or trivial copies when business requirements, retention obligations and legal holds permit. This reduces both current exposure and the amount of information that needs to be included in the migration program. Cyera data minimization
Consider a research organization with an archive that must remain confidential for fifteen years. The archive itself has a clear purpose, but the organization might also find historical exports, temporary analysis files and development copies. Some of those copies can be removed; others need an owner, a retention decision and an appropriate level of protection. Every unnecessary copy removed reduces opportunities for future collection, although it cannot retrieve information an adversary has already taken.
For the data that remains, classification needs to be combined with business context. Two datasets can carry the same sensitivity label while having very different confidentiality lifetimes, exposure and operational importance. Owners therefore need to establish how long disclosure would cause harm, why the information is retained and which business processes depend on it. NCSC’s migration guidance makes this connection explicit by including data lifetime and value to an adversary in the discovery and assessment process. NCSC migration guidance
Follow the protection as data moves
Once the organization knows which data matters most, it can examine the mechanisms protecting that data throughout its use. Encryption status is useful here, but it is only the beginning of the assessment. The relevant evidence includes the protection layer, algorithms, protocols, key references, certificates, dependent applications and responsible owners. NIST’s cryptographic inventory guidance connects these assets with the systems and sensitive information that depend on them. NIST cryptographic inventory guidance
In the research example, the archive might already use AES-256 encryption at rest. A service could nevertheless export part of that archive to an analytics provider every night, introducing transport, key-establishment and certificate dependencies that need their own assessment. The organization can have strong storage encryption while still using quantum-vulnerable public-key mechanisms elsewhere in the workflow. This is why an AES-256 label alone cannot establish PQC readiness. NCSC technical guidance
Cyera’s existing encryption-status findings provide an initial view of protection gaps around sensitive data. Customers can enrich that view with evidence from their storage platforms, cloud services, key-management systems and cryptographic tools. The purpose is to connect a technical finding to its business impact: which data depends on this mechanism, how important is that data, and who needs to make the change?
The appropriate remediation follows from that assessment. It could involve upgrading key establishment, changing key protection, rewrapping data-encryption keys or re-encrypting the underlying data. These operations have different effects on existing information and should not be treated as interchangeable. Rotating a key while retaining a vulnerable cryptographic mechanism does not resolve the quantum risk.
Connect sensitive data to the identities that use it
Understanding the protection around a dataset also requires understanding who and what can use it. During a migration that may take years, unnecessary access remains an immediate exposure. Classification helps teams focus their access reviews on the information whose disclosure would have the greatest consequences, while remediation addresses public sharing, broad permissions and access that no longer serves a business purpose.
For the research archive, the nightly export service might need access to a defined subset of records. If its identity can read unrelated datasets, or if old project groups still retain access to the archive, those permissions deserve review regardless of the migration schedule. Cyera helps prioritize these findings and supports actions such as removing inappropriate sharing, routing issues to owners and triggering remediation workflows. Cyera remediation
Key permissions need a related assessment in the relevant KMS and IAM systems. Permission to use a key, administer it and change its access policies represent different responsibilities. The assessment must also account for services that decrypt data on behalf of an authorized reader, because access to plaintext does not always require the reader to hold direct permission to use the storage key.
Non-human identities make these relationships particularly important. Service accounts, automation tools and AI agents can maintain access long after their original purpose has changed. AI pipelines also move information into preparation stores, retrieval systems, logs and external services, creating additional places where retention and permissions need to be understood.
Cyera Identity helps connect non-human identities with their owners, associated applications and reachable resources. Access Trail adds observed activity to support investigations and access reviews. Together, this context helps teams assess whether an identity still has a legitimate purpose, whether its permissions match that purpose and who should approve a change. Authentication credentials such as API keys and tokens remain distinct from the encryption keys protecting the data. Cyera Identity, Access Trail
Bring application owners and providers into the migration
The identities that access sensitive data provide a starting point for finding the applications and workflows that depend on it. Once priority data is identified, trace the service accounts, workload identities and other identities with access to the applications and processes they support. For example, a service account that reads a research archive may connect that data to an analytics pipeline, an external service and the teams responsible for them.
These relationships give application owners specific workflows to assess. Working with the relevant providers, they can validate the transport protocols, cryptographic libraries, certificates, key protection and signing mechanisms those workflows use, then determine which changes are required to protect the data throughout its movement and use.
In the research example, this means examining the complete export workflow, including the external analytics service. Security and application teams should work with risk, procurement and legal to request the provider’s migration timeline and a written readiness statement supported by technical evidence. That evidence should distinguish what is deployed today from what is planned, identify upstream dependencies and explain compatibility requirements and migration responsibilities. Relevant commitments can then be reflected in procurement, contracts and ongoing supplier reviews. NCSC recommends identifying supplier dependencies and communicating migration needs early. NCSC migration guidance
The assessment also needs to include authenticity and integrity. NIST’s foundational PQC standards cover ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. Long-lived signed contracts, software, firmware and other artifacts therefore require attention to the signing, timestamping, archival and verification processes that preserve trust in them. NIST PQC standards
With these dependencies understood, the organization can create a migration plan with accountable owners and testable outcomes. For the research workflow, that could include a provider upgrade, an application change and validation of the interaction between them. Testing should cover interoperability, performance, recovery and fallback behavior before production deployment. Meanwhile, removing obsolete exports and narrowing the service identity’s access reduces exposure while the engineering work proceeds.
Make readiness a continuing security practice
A useful readiness report connects the information requiring protection with its owners, confidentiality requirements, access paths and cryptographic dependencies. Customers can assemble that view by bringing Cyera findings together with business decisions, supplier evidence and their cryptographic inventory. The result becomes a working migration backlog that can be updated as applications, identities and data flows change.
Progress should show both preparation and implementation. Preparation includes identifying priority datasets, removing unnecessary copies, assigning owners, documenting dependencies and reviewing supplier plans. Implementation requires evidence that the relevant mechanisms have been upgraded, affected workflows have been tested and production deployment has been verified. Keeping these measures distinct makes it easier for leadership to see what has been understood, what has been reduced and what has actually been migrated.
Those measures should be attached to dates. NCSC’s published benchmarks call for discovery and an initial migration plan by 2028, highest-priority migration activities by 2031, and migration completion by 2035. Organizations can use these as planning references while setting earlier targets for their most consequential information and systems. NCSC migration milestones
Over time, this becomes the foundation for crypto-agility: the ability to locate cryptography, understand its dependencies, introduce supported mechanisms, test changes and retire obsolete ones as requirements evolve. Cyera’s contribution is to keep that work connected to the data, access and ownership decisions that give it business priority. Maintaining those relationships helps organizations protect valuable information throughout the PQC transition and adapt when the next cryptographic change arrives. NIST crypto-agility guidance
Get your AI Security Assessment
.png)
.svg)