TL;DR

Zero Trust is the technology answer, but an access stack in 2026 has to satisfy auditors, plug into hyperscaler-native identity, and — for consultants — survive being carried across a dozen client environments at once. This finale pulls the previous six parts into a single operating picture: compliance frameworks codify what Part 6 described, AWS / GCP / Azure ship ZT as managed services you can opt into, and the working life of a practitioner is the quiet proof that this stack actually holds.

This is the final chapter of From Trusted Wires to Zero Trust. It’s also a retrospective — every client anchor from Parts 1 through 6 makes a short return appearance, because a series that opened on a BT data centre floor in Tel Aviv deserves to close by revisiting everyone who shaped the journey.

Compliance is what turns a pattern into a requirement

For years Zero Trust was a preference — something a modern platform team argued for. Compliance frameworks are what converted it into a requirement that procurement and legal will not let you skip.

  • SOC 2 Trust Services Criterion CC6 (“Logical and Physical Access Controls”) is now written in the language of continuous verification. CC6.1 wants you to prove identity-based access is enforced for every resource, not just at the perimeter. CC6.6 wants evidence that access is reviewed, not just granted. An access log from a ZT proxy with identity, device posture, and outcome on every request is the easiest CC6 evidence you will ever hand to an auditor.
  • ISO 27001:2022 added Annex A control 8.3 (Information Access Restriction) and explicitly accepts “dynamic, context-based” access decisions. The old “need-to-know” language got a policy-engine upgrade.
  • NIST SP 800–207 — the canonical Zero Trust reference — is now cited directly in US federal procurement language via OMB M-22–09. If you sell to the US government, “we have a VPN” is no longer a defensible answer.
  • HIPAA and PCI-DSS 4.0 both tightened session-management and continuous-authentication requirements in their last revisions. Session-lifetime caps and re-authentication on sensitive actions are exactly what a ZT policy engine does natively.
  • FIPS 140–3 is the one place where the Zero Trust stack has to watch its footing. WireGuard (Part 4) has no FIPS-validated module, which is why US federal deployments still use IPsec with FIPS-validated crypto (Part 3) underneath the policy plane. The overlay architecture is the same; the tunnel cipher is what changes.

Auditors don’t want new controls — they want evidence of old controls, at volume. ZT produces that evidence as a side effect. That is most of the reason compliance teams stopped resisting it.

captionless image

The hyperscalers now ship Zero Trust natively

Three years ago the ZT conversation was dominated by specialists — Cloudflare, Zscaler, Tailscale, Twingate. That’s still true for cross-cloud deployments. What’s changed is that the big three now ship ZT as first-class services, and for workloads that live entirely inside one cloud, the native option is usually the pragmatic default.

  • AWS Verified Access sits in front of internal web apps and evaluates identity (from IAM Identity Center or an external IdP) and device posture (from Jamf, CrowdStrike, Jumpcloud) on every request. No agent, no VPN. Pairs with VPC Lattice for east-west service-to-service authorization.
  • Google BeyondCorp Enterprise is the commercial descendant of the original 2014 paper. Identity-Aware Proxy (IAP) gates access to GCE, GKE, and internal App Engine services by IAM identity — the Google-internal model, now sold.
  • Microsoft Entra Private Access (formerly parts of Azure AD and the MEM/Intune stack) ties Entra ID to Conditional Access and device compliance, with an on-premises connector pattern that fills the role Cloudflare Tunnel does in a SaaS stack.

The choice between hyperscaler-native and best-of-breed becomes a cost of switching conversation. Single-cloud shops gravitate to native; multi-cloud and SaaS-heavy shops still buy the overlay. Neither is wrong.

What ties them all together is OIDC federation — the same workhorse from Part 5. GitHub Actions runs a job; it exchanges a short-lived OIDC token with AWS, or GCP, or Azure, and never holds a long-lived credential. The pipeline is the identity. Your compliance auditor will ask about this by name within the next audit cycle.

🌐 DNS, as evidence and as policy

DNS has been the cross-cutting thread of this series, and in Part 7 it closes the loop twice.

DNS logs are audit evidence. Every Zero Trust resolver — Cloudflare Gateway, Cisco Umbrella, NextDNS, Google’s Chrome Enterprise resolver — emits a per-query record: client identity, query, answer, verdict. That is precisely the log-trail SOC 2 CC6.8 and ISO 27001 A.8.16 want for “monitoring activities.” You don’t need a new logging pipeline. You need to turn on the resolver’s log export.

Split-horizon DNS is how consultants stay sane across clients. If you advise three clients and two competitors, your laptop’s resolver has to behave differently depending on which VPN profile or ZT gateway is active. DoH/DoT plus per-profile resolver overrides — the thing your 1Password and Tailscale setups quietly rely on — is what keeps client A’s internal DNS out of client B’s query stream. This is a compliance requirement you’ll never see in an auditor’s spreadsheet and will absolutely come up in an incident review.

The consulting-from-anywhere stack

The selfish reason every DevOps consultant ends up enthusiastic about Zero Trust is that it is what makes distributed consulting practical. A short tour of the anchors from earlier parts, told as one working week:

  • Monday morning, I open a bank’s infrastructure console. Part 3’s OpenVPN-on-pfSense engagement — the client that taught me the “thirty-page runbook” problem — is now federated into Okta. I log in once; the VPN, the AWS console, and the GitHub org all trust the same SSO session. The runbook is a single page.
  • Wednesday, I’m in a Part 5 Keycloak shop that just rolled out oauth2-proxy in front of their internal dashboards. The day before, we finalized an IRSA migration that killed the last long-lived AWS access key. The only change to my laptop was a browser reload.
  • Thursday, the Part 6 endpoint-vendor retainer meeting. Their ZT stack now gates me on my company laptop’s EDR signal. I forgot to reboot after a patch last night; the session is flagged, I’m prompted to fix it, I reboot, I’m back in. No password was asked.
  • Friday, a Part 4 WireGuard-migration client is comparing Tailscale’s managed mesh against a self-hosted wg-quick stack. The conversation is entirely about operational burden — not about whether WireGuard works.
  • Across all four days, DNS filtering via a corporate resolver is catching two phishing domains I never saw, and logging every query for the audit I won’t have to run.

Four different clients, four different identity providers, zero VPN concentrators on my network path. This is what changed. The BT data-center floor in Tel Aviv — Part 1’s opening scene — is still there, but the trust boundary moved from the cable to my identity.

captionless image

What I’d tell my 2006 self ⁉️

The BT data-center, OpenVPN, IPsec, SSH jump boxes, WireGuard, OIDC, ZTNA, hyperscaler-native Zero Trust, compliance-driven adoption — each was unavoidable when it happened and obvious in retrospect. The pattern under all of them is the same: every layer pushed trust a little closer to the identity of the person making the request, and a little further from the network the request happens to be on. That’s the whole story. Everything else is tooling and vendor names.

Thanks for reading. The full seven-part series is cross-posted on Medium and on portfolio.hagzag.com. Every part ships a companion k3d lab at [github.com/hagzag/the-road-2-zerotrust](https://github.com/hagzag/the-road-2-zerotrust) — Parts 1 through 6 are wired up; Part 7 is the one post in the series without a lab, because its subject is the sum of the others.

📖 Further Reading