Enterprise Post-Quantum VPN Assessment and Migration
Identify which VPN connections are quantum-vulnerable, determine what your existing gateways can support, and execute a controlled migration without unnecessary infrastructure replacement.
See Assessment DeliverablesVendor-neutral assessment for site-to-site IPsec, cloud VPN gateways, proprietary appliances and Linux-based VPN infrastructure.
| Connection | Classification | Wave |
|---|---|---|
| EU Production — HeadquartersFirewall platform A, current releaseNone | Ready | 1 |
| Datacentre B — HeadquartersRouter platform B, two releases behindSoftware upgrade, both members of HA pair | Upgradeable | 2 |
| Cloud VPC — Datacentre BManaged cloud VPN gatewayCustomer gateway release not yet established | Peer-dependent | 2 |
| Clearing partner — DMZPartner-controlled applianceExternal counterparty change process | Peer-dependent | 4 |
| Branch network — HeadquartersAppliance past end of software maintenanceHardware refresh, aligns with planned cycle | Replacement required | Deferred |
| Legacy supplier linkUnmanaged, owner unidentifiedIKEv2 migration required first; owner to be established | Blocked | Deferred |
How PQVPN works
- Vendor-neutral
- Existing-infrastructure-first
- Exact model and version analysis
- Customer-managed or PQVPN-led migration
- Human-reviewed implementation artifacts
The problem
Vendor support is not the same as estate readiness.
A product announcement does not tell you whether a specific gateway, firmware release, licence, configuration and remote peer can complete the intended migration. PQVPN maps those dependencies before production changes begin.
- Ready
- Both peers already support the target mechanism. Schedule into an early wave.
- Upgradeable
- Both peers can reach the target with a software or licence change you control.
- Peer-dependent
- Your side is ready. The far end belongs to another organisation, so their change process is in your critical path.
- Replacement required
- One peer cannot reach the target on any supported release. This is a hardware decision, not a configuration decision.
- Blocked
- Something other than capability prevents it — contractual, regulatory, or an unresolved dependency with a named owner.
Two properties also have to be tracked separately. A hybrid key exchange protects the session key against an adversary recording traffic today. It does nothing for the certificate or preshared key that authenticates the peer, and configuration support does not prove the intended mode was actually negotiated.
Two connected offerings
Assess first. Then implement what the assessment approved.
Know what can migrate, what cannot, and what it will take.
Receive a verified VPN inventory, compatibility analysis against exact products and releases, a blocker register naming every dependency, prioritized migration waves, engineering runbooks and an executive decision package.
Turn the approved roadmap into controlled production changes.
PQVPN can generate vendor-specific implementation artifacts, coordinate migration waves, validate routing and failover, verify negotiated protection, and hand the environment back to your team.
How an assessment works
From scattered configuration to an executable plan
The assessment takes what your estate can actually produce and returns something your engineers and your board can both act on.
Input
Step 1What you provide
- Gateway inventory
- Tunnel configurations
- Versions and licensing
- Topology and routing
- Cloud VPN resources
- External peer relationships
- Operational constraints
Transformation
Step 2What PQVPN does
- Normalize across vendors
- Classify quantum exposure
- Research exact releases
- Score complexity
- Design target state
- Sequence migration waves
- Validate and document
Output
Step 3What you receive
- Verified inventory
- Compatibility matrix
- Readiness profile
- Blocker register
- Prioritized migration backlog
- Engineering runbooks
- Executive report
Sample finding
What a single assessment finding looks like
Every connection resolves to a statement with a named dependency, a risk level, a wave and an explicit confidence qualifier.
Assessment finding — illustrative, fictional estate
- Connection
- EU Production — Headquarters
- Technology
- IKEv2 / IPsec
- Gateway
- Example enterprise platform, release two behind current
- Current key establishment
- Classical
- Target path
- Hybrid post-quantum
- Status
- Upgradeable
- Dependency
- Remote peer configuration
- Migration risk
- Medium
- Recommended wave
- 2
- Confidence
- Requires configuration verification on both peers
Explicitly fictional. This example does not represent a customer environment.
Environment coverage
PQVPN assesses estates containing these platforms
Coverage means PQVPN will assess an estate containing these platforms. It does not mean any of them is broadly supported — capability depends on the exact product, release, licence and peer, which is exactly what the assessment establishes.
Why now
The lead time, not the deadline, is the reason to start
None of this is urgent because something happens on a particular date. It is urgent because each of these takes longer than the time you have to plan it in.
Inventory comes first, and it is slow
Nothing can be planned against an estate you cannot describe. Building an inventory from device state rather than documentation is usually the longest single step.
Long-lived confidentiality
Traffic recorded today can be decrypted later. Where data must stay confidential for a decade or more, the exposure started when the data first crossed the tunnel.
Hardware refresh cycles
Devices that cannot migrate need replacing. Aligning that with a refresh already in the budget is far cheaper than a separate capital request.
External partner coordination
A tunnel to a partner cannot be migrated unilaterally. Their change process becomes part of your timeline, and it is the longest lead time in the programme.
Change-control reality
In a regulated environment each wave carries a minimum approval cycle. The number of waves multiplies that cycle, and it cannot be compressed by adding engineers.
Published transition guidance
Recognized authorities have published transition timelines and expectations. PQVPN records those with sources and verification dates rather than paraphrasing them as pressure.
Standards and transition guidance are recorded in the standards reference, each with its source and the date PQVPN last verified it.
Ownership
Your team remains in control.
The assessment is designed for action, not for a shelf. Implement the plan internally, deliver it jointly with PQVPN, or engage PQVPN to perform the migration — the deliverables are the same either way.
Customer-led
Your engineers execute the plan using PQVPN runbooks, change plans and implementation artifacts. PQVPN stays available for questions.
Joint delivery
Your team and PQVPN split the work by platform or by wave, under a shared change plan and a single evidence set.
PQVPN-led
PQVPN delivers the migration programme, with your change control governing every window and your team receiving full handover.
About PQVPN
Why this company exists
PQVPN.com was registered in 2019, from an early conviction that post-quantum networking would become an operational infrastructure problem rather than a cryptographic research one.
That turned out to be the right frame. The hard part of a post-quantum VPN migration is not the mathematics. It is knowing which of four hundred tunnels can move, which are held back by a firmware release, which depend on a partner who has not answered an email, and in what order to change them without breaking anything.
PQVPN now focuses on exactly that: helping enterprises assess and migrate real VPN estates.
Know what your VPN estate can support before committing to hardware, licensing, or migration work.
Tell us roughly what the estate looks like. You will get a preliminary complexity band and a clear next step — not a sales call before you have learned anything.