ISMS

Zero Trust for Mid-Market Companies: Implementing the Principles Without an Enterprise Budget

TL;DR
  • Zero Trust is a security model, not a product. The core principle is: trust nobody, verify everything -- regardless of whether access comes from inside or outside.
  • The five core principles (explicit verification, least privilege, assume breach, micro-segmentation, continuous validation) can be implemented step by step even in mid-market companies.
  • MFA on all external access points, consistent least privilege, and basic network segmentation deliver the greatest security gain with the least effort.
  • Conditional access policies in Microsoft 365 or Google Workspace are already included in the license and enable context-based access control at no additional cost.
  • You need neither a SASE platform nor a full-stack ZTNA vendor to get started with Zero Trust. The principles work with built-in tools.

Why Zero Trust makes particular sense for mid-market companies

The term Zero Trust has been floating around the IT security industry for years. It appears at every trade show, in every webinar, and in every whitepaper from major vendors -- usually flanked by product announcements promising to solve Zero Trust with a single platform. No wonder many IT leaders in mid-market companies now reflexively wave it off when the topic comes up. Too abstract, too expensive, too complex for a company with 80 or 200 employees.

Yet the fundamental idea behind Zero Trust is neither abstract nor expensive. It is actually quite simple -- and highly relevant for mid-market companies in particular. Because the classic network architecture on which most mid-market IT environments are based has a fundamental problem: it trusts everything inside the network. Firewall at the perimeter, behind it a flat network where every workstation can communicate with every server. Once you are in, you are in.

This model dates from a time when all employees sat in the office, all applications ran in the local data center, and the internet was a channel you opened outward in a controlled manner. That time is over. Employees work from home, applications run in the cloud, service providers access systems remotely, and mobile devices are ubiquitous. The network boundary where the firewall handled everything no longer exists in this form.

This is exactly where Zero Trust steps in. Not as a product, not as a technology, but as a mental model that aligns security architecture with the reality of modern IT environments. And this mental model can be implemented without an enterprise budget -- if you understand what is behind it and which measures deliver the greatest leverage.

What Zero Trust really means

Before we talk about concrete measures, we need to separate the concept from vendor marketing promises. Zero Trust was formulated in 2010 by John Kindervag at Forrester Research and is based on a simple observation: the traditional trust model in networks, where internal communication is inherently trusted and external communication is inherently untrusted, is wrong.

Attackers who have made it into the internal network -- whether through phishing, a compromised service provider, or a vulnerability in a web application -- can move freely there. This is called lateral movement. The attacker jumps from system to system, escalates privileges, and accesses increasingly sensitive data. The perimeter firewall notices none of this because the traffic is internal and therefore trusted by definition.

Zero Trust flips this model. The core statement is: trust nobody, verify every access, every time. There is no more implicit trust -- not for internal users, not for internal devices, not for internal network traffic. Every access to every resource must be explicitly authorized based on the user's identity, the device's state, and the context of the request.

This initially sounds like massive effort. But the crucial point is: you do not have to implement everything at once. Zero Trust is not a switch you flip but a journey. And on this journey, there are measures that are quick and cheap to implement yet deliver enormous security gains.

The five core principles of Zero Trust

In 2020, NIST published Special Publication 800-207, a reference architecture for Zero Trust that is now considered the standard. From it, five core principles can be derived that form the foundation of every Zero Trust strategy.

1. Explicit verification

Every access is authenticated and authorized based on all available data points. Not just username and password, but also device identity, location, time of day, risk level of the request, and other contextual information. In practice, this means: multi-factor authentication for every access to sensitive resources, and ideally context-based access policies that can not only allow or deny access but also impose conditions.

2. Least privilege

Users and systems receive only the minimum permissions necessary to perform their task. Nothing more, nothing less. This principle applies to user accounts as well as service accounts, API keys, and machine identities. In many mid-market companies, this is where the greatest leverage lies -- because over the years, permissions have accumulated that nobody needs anymore but were never revoked.

3. Assume breach

Assume that your network is already compromised. Design your security architecture as if the attacker is already inside. This sounds pessimistic but is the most realistic assumption you can make. When you assume your perimeter will be breached, you automatically build defense lines inside: segmentation, monitoring, rapid detection, and contained blast radius.

4. Micro-segmentation

Divide your network into small, isolated segments. Each segment protects a specific resource or group of resources. Communication between segments is explicitly allowed, and everything else is blocked. If an attacker enters one segment, they cannot automatically access all others. Lateral movement capability is drastically restricted.

5. Continuous validation

Trust is not static. A user who logs in at 9 AM from the office with a current, managed device has a different risk profile than the same user accessing at 3 AM from an unknown IP address with an unknown device. Zero Trust requires trust to be continuously reassessed -- not just at login but throughout the entire session.

What is realistically implementable in SMEs

Now it gets practical. The five principles sound convincing in theory, but which of them can you actually implement in a company with 50 to 500 employees, a limited IT budget, and a small IT department?

The honest answer: not all of them in full scope. Continuous validation with real-time risk assessment requires technologies like UEBA (User and Entity Behavior Analytics) or XDR platforms, which are often too complex and too expensive for mid-market companies. Full micro-segmentation at the workload level with software-defined networking requires infrastructure that many SMEs do not have.

But that is no reason to dismiss Zero Trust entirely. Because principles 1 through 3 can be implemented with manageable effort and deliver the bulk of the security gain. And for principle 4, there is a pragmatic version that is far from full micro-segmentation but still makes an enormous difference.

The following table shows a realistic assessment for mid-market companies:

Principle Feasibility in SMEs Effort Security gain
Explicit verification (MFA + conditional access) High Low to medium Very high
Least privilege High Medium Very high
Assume breach (monitoring + incident response) Medium to high Medium High
Micro-segmentation (network level) Medium Medium High
Continuous validation Low to medium High Medium

The strategy for mid-market companies is therefore: focus on the first four principles in a pragmatic form. That alone dramatically raises your security level and takes you far beyond what most comparable organizations have implemented.

Concrete measures for mid-market companies

MFA on all external access points

If you implement only a single measure from the Zero Trust toolkit, make it this one: multi-factor authentication on all externally reachable services. VPN access, Microsoft 365, Google Workspace, cloud applications, remote maintenance access, admin panels. Everywhere.

MFA is the most effective single measure against credential-based attacks. Microsoft puts the protection at over 99% of account takeovers. Google reports similar numbers. The reason is simple: even if an attacker obtains a password through phishing or a data leak, they lack the second factor.

Implementation is now trivial. Microsoft 365 and Google Workspace have MFA as a built-in feature. Authenticator apps are free. For VPN access and on-premises applications, solutions like Microsoft Entra ID Application Proxy or free TOTP implementations are available.

Important: use phishing-resistant factors where possible. FIDO2 security keys or passkeys are better than SMS codes, and SMS codes are better than no second factor at all. Start with what you can implement today and improve the factors over time.

Conditional access: Context determines access

Conditional access goes a step beyond simple MFA. Instead of only checking whether the user authenticated correctly, additional contextual information is factored into the access decision. Which device is being used? Is it managed or personal? From what location does the access originate? What is the risk level of the user account?

Microsoft Entra ID (formerly Azure AD) offers conditional access policies already in the Business Premium licenses that many mid-market companies have. Google Workspace offers comparable features under the name Context-Aware Access in Business Plus licenses.

Typical conditional access rules for mid-market companies look like this: access to corporate resources only from managed devices. Access from unknown locations requires additional verification. Admin access is restricted to the corporate network or VPN. Legacy authentication protocols are blocked. These rules can be configured in a few hours and take effect immediately.

Implementing least privilege consistently

The principle of least privilege is not a new idea. ISO 27001 requires it in Annex A.5.15 (Access control) and A.8.2 (Privileged access rights). NIS2 presupposes it in the minimum measures. In practice, however, things look different in many mid-market companies.

You probably know the typical problems: the CEO has local admin rights on their workstation because they wanted to install a program three years ago and nobody ever revoked the rights. The interns have the same network drive access as the department heads because an experienced colleague's account was used as a template during setup. The IT service provider has a domain admin account that is active around the clock even though they only perform maintenance twice a month.

Least privilege means systematically cleaning up these states. Concretely, this means: revoke local admin rights on workstations. Introduce a role-based authorization concept where access rights are tied to functions, not individuals. Use admin accounts on a time-limited basis (just-in-time administration). Regularly review permissions in an access review. Separate privileged accounts from normal work accounts.

This sounds like a lot of work, and yes, the initial cleanup is effort-intensive. But once you have a clean authorization concept and a solid user lifecycle process, the ongoing effort is manageable. The security gain is enormous because you drastically reduce both insider risks and the impact of compromised accounts.

Network segmentation as pragmatic micro-segmentation

Full micro-segmentation at the workload level is typically not practical for mid-market companies. What is very much feasible, however, is meaningful network segmentation that separates the most important areas from each other.

The basic idea is simple: instead of a flat network where all devices can reach all servers, you partition your network into VLANs and regulate traffic between VLANs through firewall rules. A sensible starting setup for a mid-market company might look like this:

Segment 1 -- Workstations: All user PCs and laptops. Allowed to access application servers and internet, but not the management network or database servers directly.

Segment 2 -- Servers: Application servers, file servers, intranet. Reachable from workstations but only through defined ports and protocols.

Segment 3 -- Databases and backup: Reachable only from application servers, not directly from workstations. This especially protects backups from ransomware spreading through compromised workstations.

Segment 4 -- Management: Switches, firewalls, hypervisors, IPMI/iLO interfaces. Reachable only from dedicated admin workstations. This segment is especially critical because an attacker with access to the management network can control the entire infrastructure.

Segment 5 -- Guests and IoT: Wi-Fi for guests, printers, IP phones, other IoT devices. Isolated from the rest, with internet access but no access to internal resources.

This segmentation can be implemented with any reasonably modern managed switch and a firewall that supports VLANs and inter-VLAN routing with rulesets. Even devices in the three-digit euro range can do this. You need neither software-defined networking nor an enterprise firewall.

Monitoring and logging as the foundation for assume breach

Assume breach means in practice: you need the ability to detect unusual activities. If you assume an attacker will eventually get into your network, you must be able to notice it and react quickly.

For mid-market companies, this does not mean building a SOC with 24/7 staffing. It means establishing basic logging and monitoring: centralized collection of log data (Windows Event Logs, firewall logs, authentication logs). A structured logging strategy helps identify the right events. Automatic alerts on critical events (failed login attempts, admin actions, changes to security settings). Regular review of alerts.

Tools like Windows Event Collector, Graylog (open source), or a managed SIEM from an IT service provider make this possible even on a small budget. If you use Microsoft 365 Business Premium, Microsoft Defender for Business already provides XDR capabilities that deliver endpoint alerts and enable automated responses.

What you do NOT need

An essential part of a pragmatic Zero Trust strategy for mid-market companies is knowing what you do not need. Vendors will happily sell you more than you can meaningfully use.

You do not need a SASE platform. Secure Access Service Edge is an architectural model for enterprises with thousands of employees across dozens of locations that want to move their entire networking and security stack to the cloud. For a company with one or two locations and a manageable number of remote workers, this is overkill.

You do not need a dedicated ZTNA vendor. Zero Trust Network Access as a product category replaces classic VPN access with application-specific tunnels. This is a sound concept, but for mid-market companies, a well-configured VPN with MFA and conditional access suffices in most cases. If you want to introduce ZTNA in the future, Microsoft Entra Private Access or Cloudflare Access offer affordable entry points.

You do not need an identity governance tool with a six-figure price tag. SailPoint, Saviynt, and similar platforms are designed for large enterprises with tens of thousands of identities and hundreds of applications. For mid-market companies, a cleanly documented authorization concept, regular access reviews, and a defined user lifecycle process are sufficient.

You do not need real-time continuous authentication. Biometric real-time verification during a session, keyboard behavior analysis, and similar technologies are interesting but neither affordable nor necessary for mid-market companies. A clean session timeout policy, automatic screen lock, and regular re-authentication for sensitive actions serve the same purpose in a more pragmatic way.

Practical example: Zero Trust at a machine manufacturer with 120 employees

A mid-market machine manufacturer with 120 employees, three locations, and a small IT team of three people shaped their Zero Trust journey as follows.

Months 1-2: MFA and conditional access. The company was already using Microsoft 365 Business Premium. In the first step, MFA was activated for all users, initially with the Microsoft Authenticator app. In parallel, conditional access policies were configured: access to SharePoint and Teams only from managed devices, admin access only from the corporate network, and blocking of legacy authentication. Effort: approximately 20 work hours for IT, two weeks of lead time for employee communication.

Months 3-4: Permission cleanup. All user accounts were reviewed. Local admin rights were revoked on workstations (except for IT). Network drive access was tied to security groups matching actual roles. Old accounts from former employees and service providers were disabled. Effort: approximately 60 work hours, distributed over four weeks.

Months 5-6: Network segmentation. The flat network was divided into five VLANs: workstations, servers, backup/database, management, and guests/IoT. Firewall rules were configured to allow only necessary communication between segments. Effort: approximately 40 work hours, half of which was spent on planning and testing.

Months 7-8: Logging and monitoring. Windows Event Logs and firewall logs were centrally collected on a Graylog server. Alerts for critical events were set up: more than ten failed login attempts, admin logins outside business hours, and changes to group policies. Effort: approximately 30 work hours for setup, then 2-3 hours per week for log review.

Result after 8 months: The company purchased no Zero Trust product and hired no external consultant for a six-figure project. Yet it implemented the essential Zero Trust principles. Total costs were approximately 150 internal work hours and roughly 3,000 euros for additional hardware (managed switches for VLANs and a server for Graylog). During the company's next penetration test, the tester could no longer move laterally through the network after initial access via a phishing attack -- segmentation and revoked admin rights prevented it.

Zero Trust and ISO 27001: The connection

Zero Trust is not an ISO standard and not a certification framework. But the principles strongly overlap with the requirements of ISO 27001 and NIS2.

Explicit verification and MFA are found in Annex A.8.5 (Secure authentication). Least privilege is anchored in A.5.15 (Access control) and A.8.2 (Privileged access rights). Micro-segmentation corresponds to A.8.22 (Network segmentation). Monitoring and assume breach are found in A.8.15 (Logging) and A.8.16 (Monitoring of activities).

If you operate an ISMS per ISO 27001 and incorporate Zero Trust principles into your control implementation, you simultaneously strengthen your compliance. In an audit, you can directly map the measures to controls and have a coherent argument for your security architecture.

NIS2 requires in Article 21, among other things, risk analysis, access control, and cryptography as minimum measures. A Zero Trust-oriented architecture addresses several of these measures simultaneously because it fundamentally restricts and contextually controls access to resources.

The roadmap: Implementing Zero Trust in four phases

If you want to introduce Zero Trust in your organization, I recommend a phased approach that you can adapt to your budget and capacity.

Phase 1: Secure identities (months 1-2)

This is where the biggest quick win lies. Activate MFA on all external access points. Configure conditional access policies. Deactivate legacy authentication. Separate admin accounts from work accounts. This phase can be implemented in most environments with built-in tools -- no additional licensing costs.

Phase 2: Clean up permissions (months 3-4)

Document the authorization concept. Review all accounts and groups. Revoke local admin rights. Disable outdated accounts. Introduce a regular access review process. This phase is labor-intensive but inexpensive.

Phase 3: Segment the network (months 5-6)

Create a VLAN concept. Divide the network into meaningful segments. Define firewall rules between segments. Test that all applications still work. This phase may require hardware investments for managed switches if not already present.

Phase 4: Establish visibility (months 7-8)

Set up centralized logging. Define critical alerts. Establish a process for regular log review. Link the incident response process to logging. This phase creates the foundation for practicing assume breach.

After these four phases, you have a solid Zero Trust foundation. Building on that, you can make further improvements in subsequent months: introduce endpoint detection and response, refine segmentation, extend conditional access with device compliance, pilot ZTNA for individual applications.

Common mistakes during implementation

There are several pitfalls to be aware of when implementing Zero Trust in mid-market companies.

Wanting everything at once. Zero Trust is a journey, not a sprint. If you try to implement all principles simultaneously at full scale, you overwhelm your team and your organization. The phased approach is not only more realistic but also more sustainable because employees have time to adjust to the changes.

Introducing MFA without communication. MFA changes every employee's daily workflow. If you activate it without advance notice and explanation, you produce frustration and support tickets. Communicate early, explain the reasoning, offer a brief guide, and allow a setup period.

Revoking admin rights without alternatives. When you revoke local admin rights, employees still need to remain productive. Ensure that approved software can be installed through IT services and that there is a fast process when someone needs an application. Otherwise, people will create workarounds that are worse than the admin rights.

Network segmentation without documentation. If you segment your network but never document which device is in which segment and which communication is allowed, you create a black box that becomes a problem during the next outage. Document the network concept, maintain it, and keep it current.

Too much technology, too little process. Zero Trust is at least half a process topic. MFA and network segmentation are technical measures, but least privilege works only if the user lifecycle process is clean. Assume breach works only if there is an incident response process. Invest equally in technology and processes. In ISMS Lite, Zero Trust measures can be mapped to ISO 27001 controls and the implementation status tracked for the next audit.

Zero Trust is achievable -- for you too

Zero Trust in mid-market companies is not a contradiction. It requires no enterprise budget, no hundred-person IT department, and no SASE platform. What it requires is a clear understanding of the principles, pragmatic prioritization, and the willingness to modernize the security architecture step by step.

Start with identities -- that is where the greatest leverage lies. MFA and conditional access are quickly implemented and immediately effective. Then clean up permissions, segment the network, and build visibility. Each of these phases brings you closer to a security level that meets the state of the art while addressing the requirements of ISO 27001 and NIS2.

You will not have the perfect Zero Trust architecture on day one. But an organization that has MFA on all access points, assigns permissions based on the minimum principle, segments its network, and monitors critical events is better positioned than 90% of its industry peers. And that is exactly the point: it is not about perfection but about significant progress over the status quo.

Further reading

Implement Zero Trust systematically

ISMS Lite helps you plan Zero Trust measures, document access rights, and track progress for audits. Structured and traceable.

Install now