Building a PQC Roadmap Your Board Can Actually Approve

FINMA recommends that supervised institutions draw up a PQC roadmap by mid-2027 at the latest.

But putting “migrate to PQC” on a timeline isn't a roadmap.

A roadmap that can actually be put in front of a governing body needs to answer harder questions:‍

- What is in scope?

- What needs to move first?

- How long will migration take?

- Who owns it?

- What depends on third parties?

- What resources will be required?

- And critically: What evidence supports the target dates?

FINMA recommends a strategy adopted by the institution's most senior governing body together with an implementation plan containing milestones and priorities, including target dates for full migration and for critical processes.

That means the roadmap needs to be more than a statement of intent.

It needs to be defensible.

Start with ownership

A PQC transition crosses security, infrastructure, applications, procurement, risk and third-party management.

That means responsibility cannot sit informally between teams.

Before discovery and planning progress too far, establish clear ownership.

- Executive sponsor : accountable at governing-body level and able to secure mandate and budget.

- Operational owner : responsible for coordinating the programme across teams.

- Technical owners : responsible for the affected systems, applications and infrastructure.

- Reporting cadence : defining how progress, dependencies and risks reach senior management.

FINMA's recommendation calls for the strategy to be adopted by the institution's most senior governing body.

That makes ownership a governance question, not simply a technical one.

Discovery comes before the roadmap

A roadmap needs dates.

But target dates are difficult to defend when the organisation doesn't yet know what needs to migrate.

FINMA's inventory recommendation extends across encryption, signatures, key management and authentication within ICT systems, applications and infrastructure, including environments that are outsourced or consumed as a service.

No single discovery mechanism will find everything.

Network scanning provides one view.

Container-image scanning provides another.

Static source-code analysis can expose cryptographic dependencies inside applications.

CMDB and certificate lifecycle management integrations add system context and certificate visibility.

Cloud, OT, embedded systems, firmware, legacy environments and third-party services introduce additional blind spots. The campaign's discovery methodology explicitly identifies this multi-source approach.

That's why discovery needs to begin before the final roadmap is written.

The roadmap should be built from evidence about the environment, not assumptions about it.

Without a cryptographic inventory, there are no defensible target dates — only statements of intent.

This is one of the campaign's central arguments.

Read: Cryptographic Discovery: Why No Single Tool Can Build Your PQC Inventory →

‍

From inventory to a migration sequence

Finding cryptographic assets doesn't automatically tell you what should migrate first.

The inventory needs to be translated into priorities.

For each relevant asset or dependency, organisations need to consider questions such as:

- How long must the information remain protected?

- How difficult will the asset be to migrate?

- Which applications and business processes depend on it?

- Does the organisation control the migration itself?

- Are other systems dependent on the same cryptographic component?

This turns a cryptographic inventory into a migration sequence.

Long-lived roots, code-signing keys and information that must remain confidential for many years deserve particular attention within this analysis. The campaign methodology specifically identifies these areas when moving from inventory to prioritisation.

Crypto-agility changes the roadmap

PQC migration should not be treated simply as replacing one algorithm with another.

FINMA describes crypto-agility as the ability to replace cryptographic algorithms without far-reaching changes to the software architecture and recommends that this capability be required for newly procured and newly developed ICT systems and applications.

That introduces another useful question: How long would it take us to execute a fleet-wide cryptographic change today?

If certificates are discovered, renewed and replaced manually, changing cryptography across hundreds or thousands of systems may become a significant operational programme.

Automation therefore influences the roadmap.

Automated certificate lifecycle management, policy-based enforcement and repeatable processes can reduce the operational effort required to implement future cryptographic changes.

The roadmap should consequently consider not only what needs to migrate, but also which operational capabilities need to improve before migration can happen efficiently.

Don't leave suppliers until the end

Some of the most important dates in a PQC roadmap may be dates the institution does not control itself.

Applications may depend on external software.

Cloud services may control parts of the cryptographic stack.

Hardware vendors may determine when firmware becomes available.

Managed services may have their own migration programmes.

FINMA explicitly addresses external service providers and states that responsibility remains with the outsourcing institution. It also recommends considering crypto-agility in new and existing outsourcing relationships.

Supplier dependencies therefore belong in the roadmap from the beginning.

For critical providers, organisations should understand:

• What cryptography does the service depend on?
• What is the provider's PQC migration approach?
• Which components will require customer action?
• What are the expected release cycles?
• Which dates are outside the institution's control?
• How will crypto-agility be addressed contractually?

A roadmap that ignores suppliers may contain dates the organisation cannot actually deliver.

‍

What should ultimately reach the board?

The technical programme may contain thousands of cryptographic assets.

The board doesn't need thousands of rows.

It needs a clear view of the programme.

A useful PQC roadmap should allow decision-makers to understand:

Board questionRoadmap should showWhat are we migrating?Defined scopeWhat comes first?Risk-based prioritiesWhen will it happen?Critical and full-migration target datesWho is accountable?Executive and operational ownershipWhat will it require?Resources and budgetWhat could delay us?Technical and supplier dependenciesAre we progressing?Milestones and measurable progress indicators

The campaign briefing specifically identifies scope, milestones, target dates, accountabilities, budget envelope and progress metrics as the elements needed for a board-ready roadmap.

The objective isn't to promise a date before the organisation has enough information.

It's to create enough visibility to make the dates defensible.

‍

The roadmap is the beginning, not the end

FINMA's mid-2027 recommendation is about having the roadmap in place.

It is not a FINMA deadline for completing PQC migration.

That distinction matters.

Among the institutions in FINMA's survey that already had a specific roadmap, the expected timeframe to protect critical assets was four to five years.

The roadmap therefore marks the transition from understanding the problem to managing a multi-year programme.

A credible roadmap connects: Ownership → Discovery → Inventory → Prioritisation → Migration → Crypto-agility → Measurement

And gives senior management a defensible answer to the question:

What needs to happen, by when, and why?

‍

‍

‍