Zero Trust Architecture in 2026: Your Perimeter Is Already Breached

Your firewall is a speed bump. Your VPN is an authenticated tunnel straight into your flat network, and it is statistically the most reliably exploited box you own. Zero Trust is not a product, a vendor, or a checkbox — it is the decision to stop granting trust based on network location and start authorising every single request against identity, device, and context.

This piece covers what Zero Trust actually is under NIST SP 800-207, what the CISA Zero Trust Maturity Model demands across its five pillars, where most implementations quietly fail, and how VxCloud by prodxcloud gives you the enforcement plane across AWS, Azure, GCP, Alibaba, Linode and your own bare metal — without a big-bang rewrite.

The uncomfortable truth: you are already inside someone's kill chain

The assumption that your internal network is safe was obsolete before most of your engineers finished university. John Kindervag killed it at Forrester in 2010 with "No More Chewy Centers" — crunchy shell, soft gooey middle. Sixteen years later, the average enterprise still runs a crunchy-shell architecture with an AI chatbot bolted to the front of it and calls that modernisation.

What the data actually says, consistently, across a decade of incident reporting:

• Stolen and abused credentials are perennially at or near the top of initial-access vectors in Verizon's annual Data Breach Investigations Report. Not zero-days. Not nation-state wizardry. Valid logins.
• Exploitation of edge and remote-access devices — VPN concentrators, SSL-VPN portals, secure gateways — has grown into a dominant initial-access category, which is why CISA's Known Exploited Vulnerabilities catalog reads like a product catalogue for perimeter appliances.
• Breach cost has sat north of USD 4 million on global average for years, reaching USD 4.88M in IBM's 2024 Cost of a Data Breach edition. Dwell time, not intrusion, is what makes that number large.

The case law of the last few years is brutally specific.

Notice the pattern. In not one of these did the attacker need to break cryptography. They logged in, and then the network — flat, trusting, unsegmented — did the rest of the work for them. MITRE catalogues that second phase as Lateral Movement, TA0008, and it is the phase Zero Trust exists to make impossible.

So stop asking "how do we keep attackers out?" That question has been answered, and the answer is you can't. The correct question is: when an attacker holds a valid credential on a compromised laptop, how much of my estate do they get?

If the honest answer is "most of it," you do not have a security programme. You have a hope.

What Zero Trust actually is — and the four lies vendors sell you

Zero Trust is an architectural principle: no implicit trust is granted to any asset or user account based on physical location, network location, or asset ownership. Every access decision is made per-request, per-session, evaluated against identity, device posture, workload identity, resource sensitivity and behavioural signal — and every decision is logged.

That is the whole idea. Everything else is implementation. Now the lies.

Lie #1 — "Buy our product and you'll be Zero Trust." No. NIST is explicit that Zero Trust is a set of guiding principles used to design an enterprise architecture. There is no SKU. Anyone selling you a Zero Trust appliance has, with impressive irony, sold you a new perimeter device to defend.

Lie #2 — "Zero Trust = ZTNA = replace the VPN." ZTNA is one control covering one pillar. Replacing your VPN with an identity-aware proxy is a genuinely excellent first move — it is the highest-leverage 20% — but if your service-to-service traffic is still plaintext HTTP inside a flat VPC with a shared static API key, you have moved the problem, not solved it. The east-west traffic is the breach.

Lie #3 — "It's a two-year transformation programme." It is a continuous programme, and if you cannot show enforcement in production inside 90 days you have a governance problem, not a technology problem.

Lie #4 — "Zero Trust will slow everything down." Policy decisions run in-process at sub-millisecond latency. mTLS costs roughly 1–2 ms on a service call. Meanwhile the legacy VPN you are defending adds a mandatory hairpin through a concentrator in another region. Teams that kill the VPN routinely get faster.

NIST SP 800-207 in plain language: PE, PA, PEP

If you read one document, read NIST Special Publication 800-207. Three components matter.

• Policy Engine (PE) — makes the decision. Grants, denies or revokes access for a given subject, using enterprise policy plus external inputs: identity, device compliance, threat feeds, data classification.
• Policy Administrator (PA) — executes the decision. Establishes or tears down the communication path and issues the session credential.
• Policy Enforcement Point (PEP) — sits in the data path. Enables, monitors and terminates the connection. This is your identity-aware proxy, your service-mesh sidecar, your API gateway, your admission controller.

NIST's seven tenets, compressed:

1. All data sources and computing services are resources.
2. All communication is secured regardless of network location. Internal ≠ trusted.
3. Access is granted per-session.
4. Access is determined by dynamic policy — identity, application, requesting asset, plus behavioural and environmental attributes.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
6. Authentication and authorisation are dynamic and strictly enforced before access is allowed — a constant loop of scan, assess, adapt, re-authenticate.
7. The enterprise collects as much information as possible about asset state, network traffic and access requests, and uses it to improve posture.

Read tenet 7 again. Zero Trust without exhaustive telemetry is theatre. You cannot write dynamic policy against signals you do not collect. This is why the audit log on VxCloud is append-only and hash-chained rather than a nice table in Postgres that someone can quietly UPDATE.

The NCCoE's companion build guide, NIST SP 1800-35, is the practitioner counterpart with lab-built example implementations across commercial products. If your architect has not read it, they are improvising.

The five pillars, and how to grade yourself honestly

CISA's Zero Trust Maturity Model v2.0 is the scoring rubric US federal agencies are held to, and the cleanest self-assessment tool available to everyone else. Five pillars, four stages — Traditional, Initial, Advanced, Optimal — plus three cross-cutting capabilities.

Grade yourself. Be honest. Nobody is watching, and lying to yourself is how you end up in the table above.

The US federal mandate chain is worth knowing because it drives the vendor ecosystem you buy from: Executive Order 14028 ordered federal Zero Trust adoption; OMB M-22-09 set the FY2024 targets including phishing-resistant MFA; the DoD Zero Trust Strategy extends this to seven pillars with 91 capabilities and 152 activities and an FY2027 target. Outside the US, the UK NCSC's design principles cover the same ground with less acronym overhead.

If you sell to government, defence, health or finance, these are not someone else's homework. They are arriving in your next security questionnaire.

Why your VPN is the single worst asset on your balance sheet

A traditional VPN makes one authorisation decision — at connect time — and then issues you a routable network path. That is the entire security model. Everything after the handshake is network reachability, governed by firewall rules written by someone who left the company in 2021.

1. The credential is the crown jewel. Steal it and you get the network — not an app, not a request, the network.
2. The concentrator is internet-facing, unpatched, and running an OS you cannot inspect. CISA has issued emergency directives over these boxes. Your "security device" is your largest unaudited attack surface.
3. Session tokens survive MFA. Citrix Bleed did not beat MFA; it stole the post-MFA session. Per-session trust is not per-request trust.
4. It cannot see the request. A VPN cannot tell you that an account read 40,000 customer records at 03:12 from an unmanaged device in a country its owner is not in. It authorised a tunnel, not a query.
5. It hairpins your traffic through a chokepoint, so it is slow, and the slowness generates exception requests, and the exceptions become permanent, and the permanent exceptions become your breach.

The replacement is an identity-aware proxy that authenticates the user, validates the device, evaluates policy, and forwards a single request to a single application — with no routable network path granted, ever. Google published exactly this architecture as BeyondCorp after Operation Aurora and ran their own workforce on it without a corporate VPN. It is not theoretical. It is a decade old and battle-proven at planetary scale.

"But we still need site-to-site and machine tunnels"

Correct, and this is where the nuance lives. Encrypted transport between data centres, between clouds, and to OT and edge sites is a legitimate, permanent requirement. WireGuard — a ~4,000-line, formally analysed, in-kernel protocol since Linux 5.6 — is the right primitive for that job. The sin is not the tunnel. The sin is treating what comes out of the tunnel as trusted.

VxCloud's networking stack makes that distinction structural: managed WireGuard, OpenVPN, IPSec/IKEv2, L2TP, SSTP, OpenConnect and SoftEther for the transport layer — mesh, hub-and-spoke or site-to-site across AWS, Azure, GCP and on-prem — while authorisation stays at the request layer, enforced per call against identity and policy. You get the encrypted pipe and zero implicit trust at the far end of it. Most "VPN replacement" vendors can only give you one half.

# Transport: an encrypted multi-cloud mesh, provisioned in one command
vxcli vpn network create --name prod-mesh --cidr 10.80.0.0/16 --topology mesh
vxcli vpn peer add prod-mesh --name aws-use1 --cloud aws --region us-east-1
vxcli vpn peer add prod-mesh --name gcp-euw1 --cloud gcp --region europe-west1
vxcli vpn monitor prod-mesh --watch      # live RTT, throughput, failover

# Authorisation: still enforced per request, at the PEP, against identity.
# The tunnel grants transport. It grants NOTHING else.

Blast radius math: the only security metric your CFO understands

Security budget conversations fail because engineers argue in controls and executives think in dollars. So translate. Blast radius = the set of resources reachable by one compromised principal.

That last row is the entire business case. You are not buying "better security." You are buying a smaller number multiplied by the average breach cost, plus a reduction in dwell time, which is the multiplier on that number.

And the part CFOs love: denied requests become your best detection signal. In a flat network, lateral movement looks like normal traffic. In a Zero Trust network, lateral movement looks like a service requesting something policy never allowed — which is a page, not a forensic archaeology project six months later.

On VxCloud, every one of those decisions lands in an append-only, cryptographically hash-chained audit log with actor, resource, IP and tenant attribution, streamable in real time over WebSocket into Splunk, Datadog or ELK.

vxcli audit stream --token aud_… --json | jq 'select(.decision=="DENY")'

Hash chaining matters more than people realise. A tamper-evident log means an attacker with database access still cannot quietly excise their own footprints — the chain breaks and you know. That is the difference between an audit trail and a suggestion.

The VxCloud enforcement plane, pillar by pillar

Principles are free. Enforcement points are the product. Here is how VxCloud implements each pillar as something you can turn on this quarter.

Identity — kill the long-lived credential

• SSO via SAML 2.0 and OIDC against Okta, Entra ID, Google Workspace, JumpCloud and OneLogin, with enforced-SSO policies so nobody keeps a side-door password.
• MFA with TOTP and WebAuthn, enforced per role. WebAuthn/FIDO2 is the phishing-resistant factor OMB M-22-09 mandates and NIST SP 800-63B rates highest. If you are still on SMS OTP in 2026, you are one SIM-swap from the incident channel.
• Short-lived, scoped API tokens. VxCloud keys are environment-prefixed — xc_live_, xc_stg_, xc_dev_, xc_sbx_, xc_prev_ — so a key's blast radius is legible at a glance in a log line, stored only as a SHA-256 hash, and carrying expires_at, allowed_ips, rate_limit and read-only flags.
• Every resource is addressable, which is what makes least privilege expressible at all:

vxarn:vxcloud:<service>:<region>:<account-id>:<resource-type>/<resource-id>

vxarn:vxcloud:vpn:us-east-1:472910538812:server/3ea2a6b0-…
vxarn:vxcloud:agentcontrol:*:472910538812:agent/bd052eca-…

One grammar across VPN, Agent Control, databases, storage and workflows means one policy engine governs all of them. Policies are JSON with the non-negotiable evaluation order — explicit Deny → Allow → implicit Deny — and permissions are additive across account → workspace → resource scope.

{
  "Version": "2026-08-03",
  "Statement": [
    { "Sid": "VpnReadOnly", "Effect": "Allow",
      "Action": ["vpn:List*", "vpn:Get*", "vpn:Describe*"],
      "Resource": "vxarn:vxcloud:vpn:*:472910538812:*" },
    { "Sid": "NoProdDeletes", "Effect": "Deny",
      "Action": ["*:Delete*"], "Resource": "*",
      "Condition": { "StringEquals": { "vx:Environment": "PRODUCTION" } } }
  ]
}

Automation runs as service accounts — no console login, no password, no human's personal token that dies when they resign.

Devices — posture is an input, not a formality

Endpoint posture checks (OS version, disk encryption, MDM enrolment, EDR presence) feed the policy engine as a signal on every request, not once at enrolment. A laptop that falls out of compliance mid-session loses access mid-session. That is tenet 6 implemented literally.

Networks — micro-segmentation by identity, not by CIDR

CIDR-based rules encode a lie: that an IP address is an identity. It is not — it is a lease. VxCloud replaces CIDR allowlists with identity-based policy at the enforcement point, backed by per-tenant VPCs and subnets across AWS, Azure, GCP, Alibaba, Linode and bare metal, default-deny security groups with ports opened explicitly, mTLS between control-plane services and tenant nodes, managed L7 load balancers with automatic TLS, WAF rules for the OWASP Top 10, and multi-protocol encrypted transport for the legitimate site-to-site cases. See VxCloud Networking.

Applications & workloads — mTLS and workload identity

Human identity is solved-ish. Workload identity is where 2026's breaches are coming from, because the average microservice estate authenticates itself with a static string in an environment variable that has been in Git since 2022.

The fix is SPIFFE/SPIRE — a CNCF-graduated open standard where every workload receives a short-lived cryptographic identity (an SVID) and proves it via mTLS, with no shared secret anywhere. Combined with TLS 1.3 and automatic rotation, a stolen workload credential is worth minutes, not months.

Policy for those workloads belongs in Open Policy Agent / Rego — version-controlled in Git, unit-tested in CI, distributed to every PEP: ingress proxies, mesh sidecars, Kubernetes admission controllers. Policy-as-code turns "we have a control" into "here is the commit, the test, the reviewer and the deployment timestamp" — precisely what an auditor wants and what a spreadsheet can never provide.

Data — secrets that never touch your code

Every VxCloud workspace gets a per-tenant HashiCorp Vault namespace (KVv2, AppRole, JWT auth). Deployment secrets, SSH key pairs and registry credentials are resolved just-in-time at deploy and scrubbed from container environments. Private keys are generated server-side and never leave Vault. Data at rest is AES-256-GCM; in transit, TLS 1.3 with HSTS and forward secrecy; customer-managed keys are available for tenants who correctly refuse to let their provider hold the only key.

vxcli workspace store-credential --name PROD_DB_PASSWORD --stdin --rotate
vxcli workspace get-credential  --name PROD_DB_PASSWORD   # policy-checked, audited

Visibility — the cross-cutting pillar everyone skips

You cannot enforce dynamic policy on signals you do not have. VxCloud's Guardian console gives your team 22 built-in reconnaissance and posture tools — port and vulnerability scanning, TLS and cipher inspection, Certificate Transparency monitoring, subdomain enumeration, HTTP security-header auditing, multi-resolver DNS tamper checks, BGP/ASN routing, IP reputation, DNSBL checks, VPN/proxy detection and credential-breach exposure — run against your own estate from the same console that provisions it.

Attack surface you do not know about cannot be policy-governed. Guardian's job is to make sure "we didn't know that was exposed" stops being a sentence anyone in your organisation is allowed to say. Add continuous runtime posture with Observability and stream the whole thing to your SIEM.

Multi-cloud is where Zero Trust programmes go to die

Here is the failure I see most often in mature organisations, and it has nothing to do with technical maturity.

You run AWS. You acquired a company on Azure. Your ML team wanted GCP for TPUs. Your EU subsidiary is on a local provider for residency. You now operate four separate IAM systems, four policy languages, four audit formats and four sets of on-call engineers who each understand one of them.

Zero Trust demands a unified policy decision point. Four PDPs is not Zero Trust; it is four perimeters wearing a trench coat. The only structural fixes are:

1. One resource-naming grammar across every cloud — which is why vxarn exists, and why picking that grammar before you have twenty resource types is the single most irreversible decision in the programme.
2. One policy engine that evaluates against that grammar regardless of which cloud the resource physically lives on.
3. One audit stream with consistent actor/resource/decision attribution, so your SIEM correlation rules do not need four parsers.
4. Infrastructure as code, so policy and infrastructure ship together and drift is a failed CI job rather than a quarterly discovery.

VxCloud is built around that consolidation, with an official Terraform provider so your Zero Trust posture is reviewed in pull requests like everything else.

terraform {
  required_providers {
    vxcloud = { source = "prodxcloud/vxcloud" }
  }
}

And when your regulator, your board or your largest customer says the workload cannot leave your premises, the same control plane deploys self-hosted into your own VPC or air-gapped on-prem — BYO IdP, BYO secrets store, BYO SIEM. Sovereignty is a Zero Trust data-pillar requirement, and any vendor who cannot meet it is asking you to trust them, which is definitionally the wrong answer.

Zero Trust for AI workloads: the 2026 attack surface nobody budgeted for

New in this cycle and moving faster than most change-control processes: your AI agents are principals with credentials, and almost nobody is treating them like it.

An autonomous agent that can call tools, read from a vector store, execute code and hit third-party APIs is — from a threat-model perspective — an unsupervised employee with production access, infinite patience, and a documented susceptibility to social engineering via prompt injection.

VxCloud's Agent Control plane treats agents, models, datasets and endpoints as first-class governed resources under the same vxarn grammar and the same policy engine as your VMs and databases. That is deliberate. The moment AI infrastructure gets its own bespoke access model outside your IAM, you have re-created the flat network — this time with a language model in the middle of it.

An AI agent is a principal. Give it an identity, scope it, expire it, and log it. Anything else is negligence with better marketing.

A 90/180-day rollout that survives contact with reality

Big-bang rewrites fail. Progressive enforcement works. Ordered by risk reduction per engineering hour, which is the only ordering that matters.

Days 0–30 — stop the bleeding. Enforce phishing-resistant MFA on every admin and production path, no exceptions. Inventory and kill every long-lived credential. Turn on the audit stream to your SIEM before you change anything else, so you have a tamper-evident baseline. Run external attack-surface discovery against your own estate — you will find something exposed; everyone does. And pick your resource-naming grammar, because retrofitting identifiers later breaks every stored reference, policy and audit correlation you have written.

Days 30–90 — put a PEP in the data path. Move two or three boring, popular internal apps behind an identity-aware proxy so adoption is organic and failure modes are cheap. Enable mTLS for all new services — make it the default in your service template and the problem solves itself over time. Default-deny egress on one production segment and allowlist what breaks. Move secrets into Vault and delete them from CI variables, .env files and that one Confluence page. Write your first five policies as code, in Git, with tests.

Days 90–180 — shrink the trust, prove the control. Micro-segment production by workload identity, starting with the highest-value data store. Add device posture as a required signal for privileged access. Decommission the VPN for user access while keeping encrypted transport for site-to-site — this is the day your blast radius actually collapses. Automate the evidence, generating SOC 2 and ISO reports from the audit log rather than from screenshots. Then run a tabletop: "an engineer's laptop is compromised at 14:00 on a Tuesday." Measure blast radius, compare to your day-0 number, and put that delta on one slide. It is your programme's ROI.

Most organisations reach meaningful Zero Trust posture in 90–180 days — not because the technology is slow, but because change management is.

Compliance: the controls are ~80% the same

Zero Trust and compliance are usually run as two programmes by two teams filing two sets of evidence. That is waste — only the vocabulary differs.

The strategic point: micro-segmentation is scope reduction. Every system you can prove cannot reach cardholder data or PHI is a system out of assessment scope. Zero Trust does not only reduce breach probability — it reduces audit cost, and that is a line item finance can see. VxCloud's security and compliance posture documents the engagement models, from multi-tenant SaaS to single-tenant dedicated to air-gapped self-hosted.

Seven failure modes I see in every audit

1. "We bought ZTNA, we're done." You covered one pillar. Your east-west traffic is still a highway.
2. The break-glass account with no expiry. Every organisation has one. It has a memorable password and no MFA "in case of emergency." It is the emergency.
3. Policy written in a wiki, enforced by nothing. If it is not in the data path, it is not a control — it is a wish.
4. Audit logs that can be edited. A mutable log is a log an attacker cleans.
5. Service accounts with * permissions because someone hit a permission error at 2 a.m. and fixed it with a wildcard.
6. Device posture checked at enrolment only. Compliance is a continuous property, not a certificate.
7. Nobody measures blast radius. If you cannot state today's number, you cannot prove improvement, and your programme loses funding in the next cost review.

FAQ

Is Zero Trust a product I can buy? No. It is an architecture. You buy enforcement points, a policy engine, an identity provider and telemetry, then assemble them. VxCloud provides the enforcement plane, policy engine, resource grammar and audit trail; you bring your IdP and your judgement about what matters.

Do we have to rip out everything at once? No, and you should not. Progressive adoption is the documented successful path: internal apps behind an identity-aware proxy, mTLS mandated for new services, then legacy workloads.

How is Zero Trust different from a VPN? A VPN authorises once, at connect time, and grants a network path. Zero Trust authorises every request against user, device and application context. Stolen VPN credentials give an attacker your network. Stolen Zero Trust credentials give them one app, for minutes, with device posture checked and every request logged.

What is SPIFFE/SPIRE and do we need it? SPIFFE is an open standard for workload identity; SPIRE is its reference implementation. It replaces static service-to-service API keys with short-lived cryptographic identities. If you run more than about a dozen services, yes — the alternative is a growing pile of secrets nobody can rotate.

What's the real performance cost? Policy decisions run in-process in sub-millisecond time; mTLS adds roughly 1–2 ms per service call. Most teams see no user-perceptible impact, and many get faster after removing VPN hairpinning.

Can we keep our own OPA policies and our own IdP? Yes. Write Rego in your own repository, test it in CI, have it distributed to every enforcement point, and federate any SAML 2.0 or OIDC provider. Portability is a security property — a vendor that can only be exited by rewriting your policies has made lock-in part of your threat model.

We're a 15-person startup. Is this overkill? The opposite. At 15 people you can adopt phishing-resistant MFA, service accounts, default-deny egress and an audit stream in a week, and never have to run the horrific retrofit project that the 5,000-person companies above are running right now. Zero Trust is cheapest on day one and most expensive on day three thousand.

References

1. NIST, SP 800-207: Zero Trust Architecture — csrc.nist.gov
2. NIST NCCoE, SP 1800-35: Implementing a Zero Trust Architecture — nccoe.nist.gov
3. CISA, Zero Trust Maturity Model v2.0 — cisa.gov
4. US OMB, M-22-09: Federal Zero Trust Strategy — whitehouse.gov
5. Executive Order 14028, Improving the Nation's Cybersecurity — federalregister.gov
6. US DoD CIO, DoD Zero Trust Strategy — dodcio.defense.gov
7. Verizon, Data Breach Investigations Report — verizon.com
8. IBM Security, Cost of a Data Breach Report — ibm.com
9. Google, BeyondCorp — research.google
10. J. Kindervag, Forrester, No More Chewy Centers: Introducing the Zero Trust Model of Information Security, 2010
11. SPIFFE / SPIRE — spiffe.io
12. Open Policy Agent — openpolicyagent.org
13. IETF, RFC 8446: TLS 1.3 — rfc-editor.org
14. NIST, SP 800-207A: ZTA Model for Access Control in Cloud-Native Applications — csrc.nist.gov
15. J. A. Donenfeld, WireGuard: Next Generation Kernel Network Tunnel, NDSS 2017 — wireguard.com
16. MITRE ATT&CK, Lateral Movement (TA0008) — attack.mitre.org
17. CISA, Emergency Directive 24-01 (Ivanti) — cisa.gov
18. CISA, Known Exploited Vulnerabilities Catalog — cisa.gov
19. NIST NVD, CVE-2023-4966 (Citrix Bleed) — nvd.nist.gov
20. NIST NVD, CVE-2018-13379 (FortiOS SSL VPN) — nvd.nist.gov
21. NIST, SP 800-63B: Digital Identity Guidelines — pages.nist.gov
22. OWASP, Top 10 — owasp.org
23. Cloud Security Alliance, Cloud Controls Matrix v4 — cloudsecurityalliance.org
24. Kubernetes, Network Policies — kubernetes.io
25. Istio, Security concepts — istio.io
26. HashiCorp Vault, Documentation — developer.hashicorp.com
27. NIST, SP 800-53 Rev. 5 — csrc.nist.gov
28. UK NCSC, Zero Trust Architecture Design Principles — ncsc.gov.uk
29. VxCloud Terraform Provider — registry.terraform.io
30. VxCloud Security & Compliance — vxcloud.io/pages/web/security

Stop reading. Start enforcing.

Every day you run on network-location trust is a day your blast radius is the whole estate. The technology has existed since BeyondCorp. The standard has existed since 2020. The mandates have existed since 2021. The only remaining variable is whether you move before or after the incident.

VxCloud, built by prodxcloud, gives you the whole enforcement plane in one control plane — identity-aware access, phishing-resistant MFA and SSO, vxarn-scoped least privilege, per-tenant Vault, mTLS, micro-segmentation, multi-protocol encrypted transport, 22-tool attack-surface reconnaissance, and a hash-chained audit stream your SIEM can consume today — across AWS, Azure, GCP, Alibaba, Linode, Vultr and your own bare metal, or fully self-hosted in your VPC or air-gapped facility.

• Read the security model: vxcloud.io/pages/web/security
• See the Zero Trust architecture: vxcloud.io/pages/web/enterprise/zero-trust-security
• Networking, VPN & micro-segmentation: Networking · VPN
• Docs, CLI & guides: vxcloud.io/docs · CLI reference
• Create your account free: prodxcloud.com/auth/register

Next in this series: Zero Trust Configuration — The 90-Day Hardening Playbook, with every config file, command and verification test.