What did Phase 1 prove that Phase 2 reuses?

The October 2025 cutover's playbook — netcheck-first diagnosis, outbound-TLS connectors past double NAT, win-acme DNS-01 plus four-role binding, and a rollback plan inside a 36-hour window with zero business days lost.

Why frame this as a plan instead of a build log?

The execution facts don't exist yet — no cutover date, no transcripts, no metrics. Publishing completion claims without them would invent the record; the plan is what's verifiable today.

ZTNA Phase 2: The Plan and the Definition of Done

Q: What is ZTNA Phase 2?

The committed next step in the /now entry: moving the last Tally Prime ERP hop off the remaining legacy VPN segment onto ZTNA, so no branch still depends on a fingerprintable VPN handshake.

Q: What does done look like for Phase 2?

Every branch path dials out over TLS with no inbound ports, the connector host is the single monitored egress, certificates renew on the 60-day automation, and the old VPN segment is decommissioned — not dormant.

The /now entry carries a public commitment: “Zero Trust rollout, phase 2: moving the last Tally Prime ERP hop off the remaining legacy VPN segment onto ZTNA (follows the completed Oct 2025 cutover), so no branch still depends on a fingerprintable VPN handshake.” No post delivers on it yet. What follows is the yardstick I wrote before touching anything, so the eventual work has something to be measured against.

What Phase 1 proved

The RDS migration case study is the playbook Phase 2 inherits. Its numbers are the baseline, not the aspiration:

Diagnosis first: tailscale netcheck reporting UDP: false from affected branches confirmed ISP DPI fingerprinting WireGuard handshakes. That 30-second probe should have run during evaluation; now it is mandatory up front.
Protocol shape over protocol promises: Twingate’s connectors open outbound TCP/TLS that reads as ordinary HTTPS. No public IP and no inbound firewall rules, straight past double NAT. The decision record carries the trade openly: vendor dependency moves, and the connector host becomes the single egress to monitor.
Certificates are the second migration: the tunnel routed fine and RD Gateway still rejected every session on subject-name mismatch until the win-acme DNS-01 pipeline plus four-role binding landed. Phase 2 budgets the certificate work as its own line item, not a Saturday-night surprise.
The window holds: 36 hours, zero business days lost, rollback planned from the declaration hour. The incident narrative is the texture, and the guide hub ties all of it together.

What the last hop needs

The remaining legacy VPN segment exists for one reason: some Tally Prime path still depends on a handshake DPI can fingerprint. Retiring it means replaying the Phase-1 sequence against that specific hop. Netcheck from the branches it serves, DERP reachability for whatever relays it uses, the certificate subject names its roles present, the NAT shape in front of it, and its rollback paragraph. That sequence literally is the intake checklist. The buying process I ask of clients is the process I’m running on my own estate first.

Concretely, next steps:

Probe the hop. Per-branch netcheck plus relay reachability, recorded rather than eyeballed. The before-state should be a transcript, not a memory.
Stand up the connector. Ubuntu VM on the existing Hyper-V host, bridged to the RDS host over the private subnet, outbound TLS verified past the NAT. Same shape as Phase 1, smaller blast radius.
Bind the certificates. DNS-01 issuance plus the four-role PowerShell binding on the 60-day renewal, verified with the final-binding check rather than assumed.
Cut over inside a weekend window with the old path routable until the new path carries a full business day. Then decommission the segment, because dormant VPN endpoints are attack surface with a config file.

What done looks like

Done is falsifiable. Every branch path dials out over TLS with zero inbound ports on the firewall, the connector host is the single monitored egress, certificates renew without intervention, and the legacy segment is deleted rather than disabled. The /now entry gets updated with the outcome, and this post gets its build-log sequel with transcripts.

Status (2026-10-12): still the plan

Reviewed against the repo on 2026-10-12: no cutover date, transcript, or metric for Phase 2 exists in any committed file. The /now entry still carries the commitment as future work, and the RDS case remains the only executed cutover on record. So this URL stays a plan with its slug intact (one URL accrues authority; a sequel would split it). When the work lands, the transcript appends here under this title’s sequel section. Until then, anyone reading this as a completion report is misreading it.

Grounded vs omitted

Grounded in committed sources: the Phase-2 commitment itself (src/content/now/2026-10-current-focus.md), the cutover transcripts and timeline (RDS case), the ADR-003 verdict and trade, the certificate fix (binding guide), the incident narrative (VPN-blocks post). Deliberately omitted: any cutover date, duration, or metric for Phase 2. None exist in the repo, and publishing execution facts that haven’t happened would be fabrication. When the work lands, the sequel post will carry the transcripts. Until then, this plan is the honest record.

Honest limitations

A plan is not proof. This post proves ongoing ownership of the problem rather than completion of the work. Hiring panels should read it as intent with a verifiable checklist, not as a second cutover.
The estate may surprise Phase 1’s playbook. The last hop survived Phase 1 for a reason. Legacy clients, hardcoded addresses, something pinned. The plan assumes the same shape; the probes in step 1 exist to falsify that assumption cheaply.
No pricing, no vendor commitment beyond the record. Twingate’s free tier covers the current connector count per the case; if Phase 2 outgrows it, that decision gets its own ADR, not a footnote here.