“Zero-trust” has become marketing language for anything a vendor wants to sell. Here's what it actually means and where mid-market implementations quietly fail.
The term “zero-trust” has been applied to almost every security product sold since 2020. MFA solutions call themselves zero-trust. VPN replacements call themselves zero-trust. Identity providers, cloud gateways, endpoint agents, all of them, zero-trust.
Most of it isn't. Zero-trust is an architecture pattern with a specific definition, defined by NIST in Special Publication 800-207. It's not a product. This piece walks through what zero-trust actually is, where mid-market German firms most commonly get it wrong, and the two questions that separate a real implementation from a re-labelled perimeter.
I. What Zero-Trust Actually Is
Zero-trust is built on three core principles:
▸ Never trust, always verify: No user, device, or workload is trusted by default, even inside the network.
▸ Least privilege: Access is granted at the minimum level required, for the minimum time needed.
▸ Continuous verification: Trust is evaluated per request, not once at login, and revoked when context changes.
The NIST reference architecture defines a policy engine, a policy administrator, and a policy enforcement point. Without those three components working together, what you have is not zero-trust; it's whatever your vendor has decided to call zero-trust this quarter.
Zero-trust is an architecture. It's not a product you can buy.
II. The Four Common Failures
The same four failures show up in mid-market implementations across the DACH region:
▸ Gap 1 - MFA labelled as zero-trust: Multi-factor authentication is one component of zero-trust, a strong one. But it's the front door. Zero-trust is about what happens after the door.
▸ Gap 2 - Perimeter thinking dressed up as zero-trust: Once a user or device is inside the network, they get broad access. That's the exact model zero-trust was designed to replace. Adding an SSO login in front of it doesn't change the underlying architecture.
▸ Gap 3 - No continuous verification: Trust is evaluated once at login and treated as permanent for the session. Real zero-trust re-evaluates on every access request, especially when device posture, location, or behaviour changes.
▸ Gap 4 - No policy engine: Access decisions live in disconnected tools: the identity provider, the firewall, the endpoint agent, each with its own rules. Without a central policy engine, you cannot enforce coherent access decisions across systems.
III. What Real Zero-Trust Looks Like
A genuine zero-trust implementation has four traits that a re-labelled perimeter does not:
▸ Identity-first: Every access decision starts with verifying the identity of the requester, not their network location.
▸ Context-aware: Policies factor in device posture, time of day, location, user behaviour, and workload sensitivity.
▸ Explicit verification at every access point: No implicit trust based on being “inside” the network.
▸ Continuous evaluation: Trust is a live signal, not a one-time decision.
This is a shift in how the whole system is architected, not a new box added to an existing perimeter; which is why buying a “zero-trust product” and dropping it into a legacy environment rarely produces zero-trust.
IV. The Two Questions That Separate Real From Marketing
Two diagnostic questions cut through the vendor language quickly:
Question 1: If a device is stolen but its user credentials remain valid, what changes about its access? In a real zero-trust environment, everything changes. Device posture is checked continuously and access is revoked automatically. In a fake one, nothing changes until someone manually intervenes.
Question 2: Can you define access policies that go beyond user role? Real zero-trust supports policies based on time of day, location, device health, workload sensitivity, and behavioural signals. If your access controls only understand “who,” you don't have zero-trust; you have RBAC with extra branding.
The test is not whether you have zero-trust products. It's whether you can revoke trust automatically when the context changes.
V. The Migration Path: How Firms Actually Get There
A zero-trust architecture is not built in one project. Real transitions unfold over 12 to 24 months, and they follow a predictable five-phase pattern:
▸ Phase 1 - Identity foundation: Consolidate identity providers, enforce MFA universally, deploy strong device management. Nothing else works without this in place first.
▸ Phase 2 - Visibility: Deploy endpoint detection and logging, network flow visibility, and a security information platform that can correlate signals. You cannot enforce policies you cannot see being violated.
▸ Phase 3 - Policy centralisation: Move access decisions from individual tools (firewall rules, cloud IAM, application logic) into a central policy engine. This is where most implementations stall.
▸ Phase 4 - Continuous verification: Enable device-posture checks, behavioural signals, and dynamic risk scoring that can revoke access mid-session when trust deteriorates.
▸ Phase 5 - Least privilege by default: Rebuild access permissions from the assumption that no one should have any access they can't justify. This phase never ends; it is how the architecture stays healthy over time.
How X64 Systems Approaches This
X64 Systems is Sinabis’s managed IT service for firms where data sovereignty is a hard constraint: law firms, forensic labs, public-sector bodies, and any organisation whose sensitive data has to stay inside its own infrastructure, not in a shared cloud.
For firms building toward zero-trust from scratch, or for firms whose existing implementation has some of the gaps described above, the value is having the architecture designed and maintained by a team whose entire practice is oriented around exactly the kind of firms that can’t afford compromises; where the data stays where you control it; and access to it is treated as the serious question it is.
One conversation could close the gap. Get in touch: office@x64-systems.com
Sinabis Analytics GmbH • X64 Forensic GmbH • X64 Systems GmbH