Most explanations of the zero trust security model read like they were written for a Fortune 500 security operations centre with 40 analysts and a seven-figure budget. That is not helpful when your IT department has three people, a growing list of SaaS subscriptions, and a NIS2 audit approaching.
So what is zero trust security, really? It is a model that treats every connection as untrusted until proven otherwise. No user, device, or application gets access based on network location alone. Every request is verified, scoped to the minimum necessary, and re-evaluated as context changes. The motto that sums it up: never trust, always verify.
This guide covers the five zero trust principles in terms that map to daily operations at organisations with 50 to 400 users. Each principle includes the reasoning behind it, what it looks like in practice, and where it connects to European compliance requirements. If you already understand how to implement Zero Trust Architecture, this post covers the “why” behind each design decision.
Where the zero trust model comes from
Zero Trust originated in 2010 when Forrester analyst John Kindervag argued that trust itself is a vulnerability. His premise: stop trusting traffic just because it comes from inside your network. Never trust, always verify. NIST later codified this thinking in Special Publication 800-207, defining seven tenets that underpin most government and enterprise security strategies. Microsoft distilled these into three widely adopted pillars: verify explicitly, use least-privilege access, and assume breach.
All three frameworks agree on the core idea: no user, device, or connection deserves implicit trust, regardless of where it originates. The differences are in how many principles each framework counts, not in what they recommend.
What are the three principles of zero trust?
The three principles most commonly referenced are Microsoft’s formulation: verify explicitly, use least-privilege access, and assume breach. These three cover the foundation of any zero trust security model and appear in virtually every vendor’s documentation. NIST SP 800-207 maps to the same concepts but breaks them into seven more granular tenets.
Three principles are a good starting point. For mid-market teams, they are not enough.
Why mid-market teams need five, not three
The fourth and fifth principles, device posture and continuous evaluation, are often treated as implementation details by enterprise vendors. But for organisations managing BYOD, agentless equipment, and thin IT teams, they deserve equal standing. Skipping either one creates the blind spots attackers exploit most often.
| Framework | Principles defined | What it misses for mid-market |
|---|---|---|
| NIST SP 800-207 | 7 tenets covering resources, sessions, dynamic policy, monitoring | Written for federal agencies, not 200-person companies |
| Microsoft | 3 pillars: verify explicitly, least privilege, assume breach | Strong on identity, weak on agentless devices and OT |
| Forrester ZTX | 7 pillars across network, data, workforce, workload, device, analytics, automation | Enterprise-scale framework, no European compliance mapping |
| NCSC UK | 8 design principles for network architecture | Government focus, no NIS2 or CyFun alignment |
A SASE platform that integrates ZTNA, web security, firewall policies, and device controls delivers all five principles from a single console. This matters because mid-market teams cannot manage five separate tools for five separate principles. Tool sprawl is the enemy of zero trust adoption at this scale.
What is not a zero trust principle?
Location-based trust is not a zero trust principle. Neither is “secure the perimeter” or “trust internal traffic.” The zero trust model explicitly rejects the idea that being inside the corporate network grants any level of trust. A connection from the office receives the same scrutiny as a connection from a coffee shop. If your architecture still grants broader access to on-premises users than remote users, it is not zero trust, regardless of what label the vendor puts on it.
Principle 1: verify explicitly
Every access request must prove who is asking, from what device, and under what circumstances. No connection is trusted because it originates from a known IP address or sits behind the corporate firewall.
In practice, this means tying every connection to a verified identity through your identity provider, enforcing multi-factor authentication, and making access decisions based on context: location, time of day, device health, and the sensitivity of the resource being requested.
The mid-market gap here is stark. Organisations with fewer than 100 employees have roughly one-third the MFA adoption rate of large enterprises. Yet the vast majority of compromised accounts lacked MFA. Turning on MFA across your core applications is the single highest-impact action most mid-market teams can take this quarter.
For a 200-person company, “verify explicitly” does not require enterprise-grade conditional access with dozens of policy rules. Five to ten well-defined policies cover most scenarios: one for standard access, one for sensitive applications, one for administrative tasks, one for BYOD, and one for external contractors.
In a Zero Trust Network Access architecture, this verification happens before every session. A salesperson accessing CRM from their usual laptop in Brussels gets seamless login. The same account authenticating from an unfamiliar device in an unexpected location triggers step-up verification. The application is invisible to anyone who has not passed identity verification and device posture checks. That combination of identity awareness and application-level access is what separates ZTNA from a traditional VPN, which grants broad network access after a single authentication.
Principle 2: enforce least privilege
Every identity, whether human, service account, or machine, should access only the resources it needs for its current task. Nothing more. This is the principle that turns the zero trust security model from theory into measurable risk reduction.
This sounds obvious. In practice, it is the principle most organisations fail. Research consistently shows that identities use roughly one percent of the permissions they are granted. The other 99 percent is unnecessary attack surface. When an attacker compromises a credential, the damage is directly proportional to how much that credential can reach. Over-permissioned accounts turn a single phishing click into a company-wide incident.
The root cause in mid-market organisations is usually privilege creep. An employee starts in customer support, moves to account management, then to operations. Each role adds access rights. No role ever removes them. After two job changes, a single account can reach support tickets, financial data, and operational systems simultaneously.
Fixing this does not require a massive identity governance project. Three actions make a measurable difference:
First, define five to ten role-based access templates that match how your organisation actually works. Not one template per person, but one per job function. Second, enforce separate accounts for administrative tasks. The person who manages your cloud environment should not use the same account to check email. Third, run a quarterly access review. This can be a spreadsheet shared with department managers: “Do these people still need access to these systems?” Remove what they do not.
ZTNA enforces least privilege structurally. Users authenticate to specific applications, not entire network segments. A finance team member reaches the invoicing system but has no path to engineering resources. If their credentials are compromised, the attacker gains access to one application, not the entire network. Jimber’s platform takes this further by hiding applications from the public internet entirely. If an attacker cannot see the application, they cannot target it. The 10 common ZTNA mistakes guide covers the pitfalls that undermine least privilege in real deployments, including how broad access groups quietly accumulate over time.
Principle 3: assume breach
Design every system as though an attacker is already inside. Because statistically, they probably are, or will be soon.
Nearly nine in ten organisations experienced a lateral movement incident in the past year. The average time from initial access to lateral movement has dropped to 29 minutes, with the fastest cases measured in seconds. Over 80 percent of detected intrusions now use valid credentials and trusted tools to move through environments. No malware, no exploit. Just a stolen password and a flat network.
For mid-market organisations, assume breach translates to one question: after someone clicks a phishing link, how far can the attacker go? If the answer is “everywhere,” your architecture has a segmentation problem.
Containment starts with basic network segmentation: HR, finance, production, and guest Wi-Fi on distinct segments using existing equipment. Microsegmentation in a SASE architecture takes this further. Instead of dividing networks into zones and hoping firewall rules hold, identity-based access ensures each connection is verified individually. Users connect to specific applications, not network segments. Every zone boundary is a wall an attacker has to breach separately. More walls, smaller blast radius.
For devices that cannot run software agents, such as printers, IoT sensors, meeting room systems, and industrial equipment, inline isolation hardware restricts communication to only explicitly approved destinations. Jimber’s NIAC hardware is purpose-built for this. It creates a secure bridge between IT and OT environments without disrupting production systems or requiring software installation on the device itself. This closes the gap that the ransomware prevention playbook identifies as the primary entry point for lateral movement in manufacturing and healthcare environments.
Principle 4: validate device posture
Identity alone is not enough. A verified user on a compromised device is still a risk.
Device posture checks verify security signals before granting access: is the operating system current? Is full-disk encryption enabled? Is endpoint protection running? Devices that fail these checks receive restricted access, not a flat denial, but a narrower scope that limits exposure until the device is remediated. The complete device posture guide covers configuration step by step, including how to map posture checks to specific CyberFundamentals controls for your NIS2 audit.
The challenge for mid-market teams is the agentless gap. Managed laptops can run posture agents. Printers, IoT sensors, CCTV cameras, and industrial controllers cannot. These are not edge cases. Research shows that three-quarters of cybersecurity incidents involved unknown or unmanaged assets, and the vast majority of ransomware attacks in recent years involved unmanaged devices as an entry point.
Traditional zero trust frameworks acknowledge this problem but rarely offer a practical solution. Jimber addresses it with NIAC hardware: inline isolation appliances that enforce allow-listed communication flows without requiring software on the device. A printer communicates only with the print server. A PLC on the factory floor reaches only the MES system and its update server. Everything else is denied by default. This is what “validate device posture” looks like for devices that cannot participate in authentication themselves.
A practical phased approach works for most mid-market teams. Phase 1 covers the mandatory baseline: OS currency, full-disk encryption, and active endpoint protection. Phase 2 adds screen lock, secure boot, and browser version checks. Phase 3 introduces certificate-based device identity. Organisations should implement two-tier access from the start: compliant managed devices get full access; BYOD or failed-posture devices get browser-only access with limited scope. Jimber’s ZTNA platform enforces these tiers automatically, with posture evaluation happening before every session, not just at initial login.
Principle 5: evaluate continuously
Trust is not a permanent state. A session that starts as low-risk can become high-risk the moment context changes. This principle is what separates a genuine zero trust model from a traditional VPN with extra steps.
Continuous evaluation means re-assessing access decisions throughout a session, not just at login. If a device’s posture degrades mid-session, if a user’s behaviour becomes anomalous, or if a session migrates to an untrusted network, the access scope should adjust automatically. In a traditional VPN model, authentication happens once and the tunnel stays open for hours. In a zero trust security model, every change in context is a new decision point.
For a two-to-five-person IT team, manual monitoring is not realistic. The key is consolidation and automation. Pre-configured alerts replace manual log review: failed login spikes, impossible travel patterns, new admin account creation, bulk data downloads. Policy-based auto-response downgrades non-compliant devices to restricted access without human intervention.
This is where east-west traffic monitoring becomes a force multiplier. Instead of relying on perimeter logs that only see traffic entering and leaving your network, monitoring internal flows surfaces the lateral movement that constitutes the real threat. In a unified SASE platform, detection and response happen in the same console. There is no switching between tools, no manual firewall rule changes, no waiting for a network engineer to update an ACL.
Jimber’s single management console covers ZTNA, Secure Web Gateway, Firewall-as-a-Service, and SD-WAN in one cloud-managed interface. That means one unified log stream instead of five, automated compliance evidence instead of manual report assembly, and consistent policy enforcement across all users, locations, and devices. For service partners managing multiple customers, the multi-tenant architecture provides per-customer visibility from the same platform. Continuous evaluation becomes operationally feasible because the platform does the evaluation. Your team reviews the results.
Why NIS2 makes zero trust principles a compliance requirement
NIS2 Recital 89 explicitly names zero-trust principles as a baseline cyber hygiene practice for essential and important entities across the EU. This is not guidance or a recommendation. It is a compliance expectation.
Article 21 requirements map directly to the five principles:
| NIS2 Article 21 requirement | Zero Trust principle it maps to |
|---|---|
| Access control policies and multi-factor authentication | Verify explicitly, enforce least privilege |
| Network security and segmentation | Assume breach |
| Incident handling and 24-hour early warning reporting | Evaluate continuously |
| Supply chain security and vendor access controls | Enforce least privilege |
| Encryption and cryptographic policies | Assume breach |
| Management accountability and personal liability | Governance across all five principles |
Belgium was the first EU member state to fully transpose NIS2. The CyberFundamentals (CyFun) framework, updated in October 2025 to align with NIST CSF 2.0, is the primary compliance pathway. The CCB’s own analysis shows that Basic-level CyFun controls address the vast majority of common attacks, with Important-level and Essential-level covering progressively more sophisticated threats.
The deadline is real: Belgian NIS2-regulated entities must submit their CyFun self-assessment or ISO 27001 documentation by April 2026. Cyberattacks in Belgium increased 165 percent in 2025 to an average of 275 per day. Only 46 percent of Belgian organisations have implemented MFA on external connections. The state of mid-market cybersecurity in Belgium report covers the full threat landscape and what is actually working.
A unified SASE platform simplifies compliance because the controls that enforce zero trust principles also generate the audit evidence NIS2 requires. Access decisions, device posture evaluations, policy changes, and security events are logged centrally and version-controlled. When the conformity assessment body reviews your Protect controls, you demonstrate that technical controls are active, measured, and improving, all from one console.
Ready to see what zero trust principles look like running in your environment? Book a demo and walk through the five principles applied to your users, devices, and sites.
FAQ
Are three or five zero trust principles the right number?
Microsoft and NIST define three foundational principles covering identity, access, and breach containment. These three form the core of the zero trust model and appear in every major framework. For mid-market organisations managing BYOD, agentless equipment, and small IT teams, device posture validation and continuous evaluation deserve equal standing. They are the principles most often skipped and most often exploited.
What is zero trust security in simple terms?
Zero trust security is a model where no user, device, or connection is trusted by default. Every access request is verified based on identity and context, limited to the minimum required, and re-evaluated as conditions change. The principle “never trust, always verify” replaces the older assumption that anything inside the corporate network is safe.
Does my organisation need Zero Trust for NIS2 compliance?
NIS2 Recital 89 explicitly names zero-trust principles as a baseline practice. Article 21 requires access control, segmentation, and incident handling capabilities that map directly to Zero Trust. While Zero Trust is not the only path, it is the most efficient way to satisfy multiple NIS2 requirements simultaneously. The NIS2 compliance checklist covers the full set of controls.
Can a mid-market team with three IT staff implement Zero Trust?
Yes, if you consolidate. Running five separate security tools is not viable with a small team. A SASE platform that integrates ZTNA, web security, firewall controls, and device posture into one console makes zero trust manageable. Start with MFA and per-application access for your most sensitive applications, then expand.
What about devices that cannot run security agents?
Printers, IoT sensors, industrial equipment, and building management systems need inline isolation. Jimber’s NIAC hardware enforces allow-listed communication flows without requiring software on the device. This closes the agentless blind spot that traditional zero trust frameworks acknowledge but rarely solve.
How does Zero Trust differ from traditional network segmentation?
Traditional segmentation divides networks into zones using VLANs and firewall rules. The zero trust model goes further: access is tied to identity and device health, enforced per application, and re-evaluated continuously. The segmentation vs microsegmentation comparison explains the practical differences in a SASE context.
Where should we start if we have no Zero Trust controls today?
Three actions in order: enable MFA on all external-facing applications, replace VPN with per-application ZTNA for one user group, and isolate agentless devices behind controlled access points. These deliver measurable risk reduction within weeks and create the foundation for a broader zero trust security model.
