Zero Trust Architecture is not a product you buy. It is a security model built on one principle: no user, device, or connection is trusted by default, regardless of where it originates. Every access request is evaluated explicitly, every time.
For mid-market IT teams managing hybrid workforces, SaaS applications, and a growing mix of managed and unmanaged devices, this shift from perimeter-based security to identity-based access is no longer optional. It is the only model that reflects how organisations actually operate today.
How to implement Zero Trust Architecture: quick overview
- Define what you are protecting: map users, devices, applications, and data
- Establish identity as the primary control point with strong authentication
- Enforce least-privilege access per application, not per network segment
- Add device posture checks before granting any session
- Isolate agentless devices using inline network controls
- Centralise policy management and logging in one console
- Run in monitor mode first, then enforce, then iterate
Why the perimeter model no longer holds
The classic firewall approach treats the network boundary as the main line of defence. Once you are inside, access is broad. That model worked when employees sat in offices, applications ran in on-premise datacentres, and devices were IT-issued and IT-managed.
None of those conditions reliably apply anymore. Users connect from home, hotels, and client sites. Applications live in the cloud. Printers, cameras, IoT sensors, and industrial controllers sit on the same network segments as critical business systems.
The result is a large, flat attack surface. An attacker who obtains valid credentials, or compromises one poorly segmented device, can often move laterally through an environment without hitting a meaningful control point. Network segmentation helps at the edges, but it does not prevent lateral movement once someone is inside a segment.
Zero Trust closes that gap by removing implicit trust from the equation entirely. Every connection is evaluated on identity, device state, and the specific resource being requested, not on network location. If you want to understand the broader framework this fits into, our SASE overview covers how Zero Trust connects with SD-WAN, SWG, and the rest of the stack.
The core principles: what NIST SP 800-207 actually says
NIST Special Publication 800-207 is the reference framework most organisations use when designing a Zero Trust Architecture. It does not prescribe specific products; it defines the logic that should govern access decisions.
The key concepts are:
All resources are treated equally.
Whether a resource sits in a private datacentre or a SaaS platform, it requires the same level of verification before access is granted.
Access is granted per session.
Authenticating once to a network does not carry forward. Each connection to a resource is evaluated independently.
Policies are dynamic and context-aware.
The decision to grant access considers identity, device health, time, location, and requested resource. A session that starts as low-risk can be re-evaluated if context changes.
All assets are monitored continuously.
Devices, users, and connections are not trusted indefinitely. Signals are collected and reviewed to detect anomalies.
Least privilege is the default.
Users and devices receive only the minimum access required for a specific task. Nothing more is granted automatically.
These principles translate into three operational habits that Zero Trust teams internalise: assume a breach is already underway, verify every access request explicitly, and limit the blast radius of any incident by keeping access scopes tight.
The components that enforce Zero Trust in practice
A Zero Trust Architecture is built from several technical controls working together. Understanding what each layer does helps you sequence implementation sensibly.
Zero Trust Network Access replaces broad VPN tunnels with application-specific access. A user authenticates, their device posture is checked, and they are given access to the one application they need, nothing else. Lateral movement to adjacent systems is structurally prevented. If your organisation is currently running a VPN and considering a move to ZTNA, the IPsec vs ZTNA migration comparison covers the practical trade-offs.
Secure Web Gateway and Firewall-as-a-Service apply consistent policy to outbound and web traffic. Category filtering, threat blocking, and centralised policy enforcement replace the patchwork of on-premise appliances that many mid-market teams manage today.
SD-WAN provides resilient, secure connectivity between sites without the overhead of MPLS or traditional branch firewalls. Traffic is routed intelligently and policy is applied consistently across locations.
Device Posture Checks gate access based on whether a device meets a defined baseline. OS version, disk encryption, and security configuration are evaluated before a session is permitted. A device that fails the check does not get through, regardless of whether the user identity is valid.
Inline isolation for agentless devices handles the devices that cannot run an agent: printers, cameras, IoT sensors, industrial controllers. These are placed behind a network isolation component that limits their reachable destinations to only what is necessary. This creates a secure IT-OT bridge without disrupting production systems or requiring extensive re-architecture. Jimber’s NIAC hardware is purpose-built for exactly this use case.
Centralised management ties these controls together. When policies, logs, and alerts live in separate consoles, operational overhead grows and gaps appear. A single management interface reduces configuration errors and gives IT teams the visibility they need to respond quickly.
A step-by-step implementation plan
Zero Trust implementations that fail typically try to do too much at once. The organisations that succeed pick a starting point, prove value, and expand systematically.
Step 1: Map your protect surface.
Identify the applications, data, and devices most worth protecting first. Not every system needs to move simultaneously. Start with the highest-value, highest-risk combination: remote access to internal business applications, for example.
Step 2: Inventory identities and devices.
List users, service accounts, contractors, managed devices, and agentless devices. Assign data sensitivity classifications to applications. This inventory becomes the foundation for every policy you write.
Step 3: Define minimal access paths.
For your pilot scope, map exactly which users need access to which applications, and from which device types. Whiteboard the smallest set of flows that the business requires. This is where you identify what you can eliminate.
Step 4: Integrate your identity provider.
Connect your IdP to your Zero Trust access layer. Organise groups around business roles, not organisational hierarchy. Role-based groups tied to specific workflows are more auditable and easier to maintain than broad department groups.
Step 5: Author policies in monitor mode.
Write explicit allow rules for the flows you have mapped. Run everything in monitoring before you enforce. This surfaces gaps and edge cases without breaking production access.
Step 6: Enforce and handle exceptions cleanly.
Once monitoring shows your policies are accurate, flip to enforcement. Build a time-bound exception process for anything outside the allow list. Every exception should have a named owner and an expiry date.
Step 7: Expand by zone.
Migrate additional applications and user groups in phases. Apply device posture requirements progressively, starting with administrative access where the risk is highest. Deploy inline isolation for agentless devices as you reach each network zone.
Step 8: Automate and document.
Use API-driven policy management to keep configuration consistent and version-controlled. Export logs to your SIEM. Document the operating model with review cycles and approval workflows. This evidence supports NIS2 and DORA audits.
Common mistakes that undermine Zero Trust projects
Replicating VPN access patterns.
Moving from a VPN to a ZTNA solution but granting the same broad access defeats the purpose. Policies must be written at the application level, not the network level. Our post on common ZTNA implementation mistakes covers this pattern in depth, including how exposed RDP ports often survive migrations unnecessarily.
Skipping device posture.
Identity verification alone is not enough. A valid username from a compromised device is still a compromised session. Device state checks are not optional in a Zero Trust model.
Ignoring agentless devices.
Printers, meeting room systems, and industrial equipment left on shared segments create the lateral movement paths that Zero Trust is designed to close. Inline isolation is required for these devices, not just a preference. Teams securing factories and production floors will find the industrial OT security use case a useful reference for how to approach this.
Big-bang migrations.
Attempting to migrate every user and application simultaneously introduces too many variables. Phased rollouts by application and user group are more reliable and easier to troubleshoot.
Treating it as a one-time project.
Zero Trust is an operating model, not a deployment milestone. Policies need review cycles. Inventories need updating. Access that was appropriate six months ago may not be appropriate today.
How Jimber makes Zero Trust practical for mid-market teams
Jimber delivers Real SASE in one cloud-managed platform, which means the components described above are unified rather than assembled from separate vendors. ZTNA, SWG, FWaaS, and SD-WAN share a single policy model and a single management console. There is no policy drift between tools, no duplicate user groups to maintain, and no separate log streams to reconcile.
For agentless and industrial devices, Jimber’s NIAC hardware and industrial network controllers provide the inline isolation layer that brings these assets under Zero Trust controls without disrupting operations. This covers the IT-OT integration gap that most SASE platforms leave unaddressed.
The platform is built with a partner-first model, meaning MSPs can manage multiple customer environments from one multi-tenant console using consistent templates. If you manage security for multiple clients, the managed service provider use case explains how the multi-tenant model works in practice. Pricing is transparent, without consumption-based billing that becomes unpredictable at scale.
Device posture checks and identity-based access are active by default, not add-ons. For teams navigating NIS2, GDPR, or DORA requirements, the centralised logging and API-first architecture provide the audit trail and reporting capability that regulators expect.
Practical examples in a European context
A Belgian municipality with distributed offices can deploy ZTNA to ensure that field workers access only the applications relevant to their role, while back-office systems remain invisible to unrelated devices. Cameras and access control hardware sit behind inline isolation with outbound rules locked to specific destinations. Central IT manages all of this from one console. The multiple location security use case covers this pattern in more detail.
A manufacturing plant connecting IT and OT environments can use industrial network controllers and NIAC appliances to give operators identity-based access to specific HMIs and historians, while production equipment runs without agent dependencies. Maintenance windows become time-bound, audited sessions rather than persistent open paths.
An MSP serving multiple mid-market clients can standardise on a single platform with reusable policy templates, avoiding the tool sprawl that drives up support costs and creates inconsistency across tenants.
Aligning Zero Trust with NIS2 and European compliance
NIS2 requires essential and important entities to demonstrate risk management practices, incident containment capabilities, and access governance. Zero Trust Architecture directly satisfies these expectations: least-privilege access creates documented, auditable boundaries; micro-segmentation limits blast radius; centralised logging provides the evidence trail auditors need.
GDPR expects that access to personal data is limited to what is necessary. ZTNA enforces this at the session level, per application, per user. The posture check adds a device-level confirmation that the endpoint accessing sensitive data meets your security baseline.
DORA extends these expectations to financial services supply chains, requiring resilience in third-party and contractor access. Time-bound, monitored access for external parties, combined with strict posture requirements, aligns directly with what DORA expects organisations to demonstrate.
FAQ
Is Zero Trust Architecture only for large enterprises?
No. Mid-market organisations benefit significantly because they typically have smaller IT teams and less tolerance for incident recovery costs. Cloud-managed platforms make Zero Trust accessible without the project overhead that legacy enterprise deployments required.
Does Zero Trust replace firewalls?
Not entirely. Firewalls remain relevant for north-south traffic controls and certain perimeter functions. Zero Trust changes how internal access is managed and removes the implicit trust that made compromised perimeter credentials so damaging.
How long does implementation take?
A first meaningful deployment covering a pilot application group and core user population can be done in weeks, not months. Full migration across all applications and sites is a phased process measured in quarters.
What about devices that cannot run an agent?
Inline isolation components handle these. Agentless devices are placed behind a network isolation appliance that enforces source identity and restricts outbound flows to approved destinations only. This closes the blind spot without requiring production downtime.
How does this support NIS2 audits?
Zero Trust generates the access logs, policy versions, and incident containment evidence that NIS2 expects. If your platform is API-first and exports to SIEM, the reporting overhead for audits drops significantly.
Ready to build Zero Trust that your team can actually run?
Book a demo and see how Jimber’s integrated SASE platform delivers Zero Trust Network Access, web security, and IT-OT integration in one cloud-managed console, without the complexity that holds most implementations back.
Related reading
