Core product 1
Post-Quantum VPN Readiness Assessment
Build a verified inventory, identify compatibility and blockers, and turn an uncertain VPN estate into an executable migration program.
Who it is for
Estates complex enough that the answer is not obvious
The assessment earns its cost when the estate cannot be described accurately from memory. That is usually a function of diversity and dependency rather than of size.
A good fit when
- More than one gateway vendor or platform family is in production
- At least one cloud VPN gateway is in the estate
- Some tunnels terminate on equipment you do not control
- Documentation is partly stale and nobody fully trusts the inventory
- Some devices are approaching or past end of software support
- The data crossing some tunnels must stay confidential for years
- A defensible plan is needed for a board, an auditor or a customer
Probably not yet when
- The estate is a handful of tunnels on a single platform you fully control
- You already have a trusted inventory with exact releases and peer ownership
- The migration decision is blocked on something other than information
In those cases the migration guide and the checklist may be all you need. Both are free and neither requires a conversation.
Scope
What is assessed
| Area | What is established |
|---|---|
| Gateways | Exact model, running release, licence tier, support lifecycle status |
| Tunnels | Both peers, IKE version, negotiated proposal, what the tunnel carries |
| Peers | Internal or external ownership, and the change process behind each one |
| Key establishment | The mechanism in use today and the mechanisms the platform could reach |
| Authentication | Tracked separately, because it migrates on a different timeline |
| Versions and licensing | Where capability is gated by release or by licence tier |
| Routing | Static or dynamic, and what a renegotiation would disturb |
| High availability | Cluster membership, member consistency, failover behaviour |
| Cloud integrations | Managed VPN configuration, policy pinning, IaC ownership |
| Partner dependencies | Which counterparties gate which tunnels, and their contacts |
| Operational constraints | Change-control regime, maintenance windows, documentation quality |
Required inputs
What you provide, and how it is handled
What is needed
- Gateway inventory with exact model and running software version
- Tunnel configurations, including proposals and lifetimes
- Vendor and firmware versions read from device state
- Topology and routing information
- Cloud VPN configuration exports or read-only access
- Which peers are controlled by external counterparties
- Operational constraints, change-control regime and maintenance windows
- Compliance and data-retention context
How sensitive information is handled
Configuration transfer, storage, residency and retention are agreed in writing before anything is sent, and the mechanism is chosen to suit your environment — including environments with restricted external connectivity. The assessment is designed to work from exports rather than from live access.
Process
How the assessment runs
Scope
Agree estate boundaries, what evidence already exists, how configuration will be transferred, and who owns each decision.
Collect
Gather configuration and version data from device state, management platform exports and cloud provider APIs. Anything derived from documentation rather than a device is flagged as unconfirmed.
Normalize
Reduce multi-vendor configuration to one comparable model, so a Cisco tunnel and a cloud VPN tunnel can be assessed against the same criteria.
Assess
Establish capability per exact platform, release and licence, and per tunnel against the weaker of its two peers. Research is recorded per combination, not per device.
Plan
Classify every tunnel, register every blocker with a named owner, and sequence the migratable population into waves ordered by risk and dependency.
Review
Every finding and recommendation is reviewed by an engineer before it reaches you. Automation assists the research; it does not approve the conclusion.
How complexity is scored, and what the score does not mean, is shown by the preliminary complexity calculator.
Deliverables
What you receive
Every deliverable has a named audience. The engineering outputs are built to be executed; the executive outputs are built to be decided on.
| Deliverable | Audience | Purpose |
|---|---|---|
| Verified VPN inventory | Engineering | The trusted description of the estate that everything else is built on |
| Readiness and compatibility matrix | Engineering | What each connection can support, and against which exact release |
| Environment complexity profile | Both | Explains why this estate costs what it costs to migrate |
| Blocker register | Both | Every reason a tunnel cannot move now, and what would change that |
| Prioritized migration backlog | Engineering | What to do, in what order, with dependencies stated |
| Proposed migration waves | Both | How the work fits your change-control regime |
| Engineering runbooks | Engineering | So your team can execute without PQVPN present |
| Executive report | Executive | Scope, cost, risk and the decisions that need approval |
| Fixed-scope migration proposal | Executive | A priced option to have PQVPN deliver the plan, if you want it |
Scope and pricing
Priced from complexity, not from tunnel count
Two estates with the same number of tunnels can differ by an order of magnitude in assessment effort. A per-tunnel price would be simple, and it would be wrong often enough to be useless.
- Estate size — gateways and tunnels, though never tunnel count alone
- Vendor and platform diversity, which multiplies the research surface
- Topology and routing complexity
- Number of externally controlled peers
- Legacy dependencies and end-of-support hardware
- Business criticality of what the tunnels carry
- Compliance and evidence requirements
- Change-control constraints and available maintenance windows
- Quality of existing documentation
The scoping form returns a preliminary complexity band from these drivers immediately, before any conversation. It is a scoping aid, not a diagnosis — exact scoping requires configuration and version review.
What happens next
Three ways the migration gets delivered
The assessment output is identical in all three cases. Choosing PQVPN to deliver is an option, never a dependency.
Your team implements
You take the runbooks, change plans, rollback procedures and implementation artifacts, and execute internally. PQVPN stays reachable for questions. This is a normal and fully supported outcome.
Joint delivery
Work splits by platform or by wave. One shared change plan, one evidence set, and your engineers gain the platform knowledge as the programme runs.
PQVPN-led migration
PQVPN delivers the programme under your change control, with full handover of evidence, runbooks and any remaining open dependencies at the end.
Questions
Assessment FAQ
Scope an assessment
Describe the estate in broad terms and you will get a preliminary complexity band and a clear next step. No configuration required, and no meeting before you have learned something.