Zero Trust network access and microsegmentation design for UK SMEs

Zero Trust network access and microsegmentation are often discussed together, but they solve different problems. Zero Trust network access, or ZTNA, controls how users, devices, and services get to applications. Microsegmentation controls what can talk to what once something is inside your environment. Used together, they can reduce the blast radius of a compromised account, laptop, server, or cloud workload.

For UK SMEs, the value is usually not theoretical. Hybrid work, SaaS sprawl, remote administration, and ransomware all make flat networks harder to defend. A well-designed access model can reduce lateral movement, make privileged access easier to govern, and give your security team clearer signals when something behaves unexpectedly. If you are already thinking about broader security architecture, it is worth aligning this work with your wider design principles, as discussed in aligning security architecture to business objectives and secure-by-design principles.

What Zero Trust network access and microsegmentation are, and how they differ

ZTNA is an access broker pattern. Instead of placing a user on the internal network and trusting everything behind that connection, the broker evaluates identity, device posture, location, risk, and policy before granting access to a specific application. In practice, this means the user gets access to an app, not the network. That distinction matters because it removes the assumption that being connected equals being trusted.

Microsegmentation is about dividing workloads, servers, and sometimes endpoints into smaller trust zones and enforcing explicit allow rules between them. This is usually described as east-west control, meaning traffic between internal systems rather than traffic entering or leaving the organisation. If a workstation or server is compromised, segmentation is what stops the attacker from moving freely to file shares, databases, admin interfaces, or backup systems.

Where ZTNA fits in the access path

ZTNA normally sits in front of user access paths. A common pattern is identity provider plus conditional access plus ZTNA broker plus application. The identity provider authenticates the user, conditional access checks device compliance or risk, and the broker publishes only the required application. This is a cleaner model than VPN access for many SMEs because it narrows exposure and makes policy decisions more explicit.

In Microsoft-heavy environments, this often means using Microsoft Entra ID for identity and conditional access, then publishing applications through a ZTNA-capable service or application proxy. The important point is not the brand, but the control objective: access should be granted per application and per context, not by handing out broad network reach.

How microsegmentation limits east-west movement

Microsegmentation works best when you think in terms of application dependencies rather than IP ranges alone. A web tier may need to reach an application tier on one port, and the application tier may need to reach a database on another. Everything else should be denied by default. This is especially useful for containing ransomware, credential theft, and abuse of remote management tools. It also complements network detection work, because unusual internal connections become easier to spot when the allowed paths are tightly defined. If you want a deeper view of the detection side, see Integrated Network Detection and Response architecture design.

When this design pattern makes sense for an SME

This approach makes sense when your environment has enough complexity that broad trust is becoming a liability. Typical drivers include remote staff, third-party support access, cloud and on-premises hybrid estates, and business systems that contain sensitive data or operationally critical processes. If you have already seen that a single compromised account can reach too much, segmentation is usually worth the effort.

It is also relevant where you need stronger control over privileged access. Admin accounts should not have the same network reach as standard users, and service accounts should not be able to browse the environment like a human user. ZTNA and microsegmentation help separate those paths.

That said, not every SME needs a large-scale segmentation programme on day one. If you have a small, simple estate with a single office, a few cloud services, and strong endpoint controls, you may get more value from tightening identity, device management, and backup resilience first. Segmentation should be proportional to the risk and the operational overhead you can support.

Common drivers such as remote access, hybrid work, and ransomware resilience

Remote access is the most obvious trigger. Traditional VPNs often place users too close to internal resources. Hybrid work increases the number of unmanaged paths into systems. Ransomware increases the cost of lateral movement, because once one host is compromised, the attacker will usually try to reach file servers, domain controllers, backup repositories, and admin consoles.

Microsegmentation does not stop initial compromise, but it can slow or block the next steps. That buys time for detection and response, and often reduces the number of systems that need to be rebuilt. For SMEs that rely on a small number of critical applications, that containment can materially reduce disruption.

Situations where simpler controls may be enough

If your main risk is a small number of user endpoints with limited internal connectivity, then strong identity controls, endpoint hardening, patching, and immutable backups may deliver better return on effort. Likewise, if your applications are already isolated in separate cloud accounts or subscriptions with tightly controlled security groups, you may already have a form of segmentation in place.

The key is to avoid architecture for its own sake. A design that is too complex to operate will drift, and drift creates gaps. Start with the places where trust is currently too broad and where the business impact of compromise is highest.

Start with a practical trust and traffic model

Before you buy tools or write rules, map the trust relationships. The goal is to understand who needs access, from what device, to which application, and over which path. A simple data-flow diagram is often enough to start. Identify users, devices, applications, data stores, administrative interfaces, and third-party connections. Then mark where trust changes.

For example, a finance user on a managed laptop may need access to an ERP application, but not to the database behind it. A support engineer may need temporary access to a management interface, but only from a managed device and only during approved hours. A backup server may need to write to storage, but it should not be able to initiate connections to user subnets. This kind of modelling is closely related to the threat modelling approach described in Threat modelling using STRIDE for system architects and the use of data-flow diagrams.

Identify users, devices, applications, and data flows

Build an inventory that is good enough to support policy decisions. You do not need perfection, but you do need enough detail to avoid guessing. Capture the following for each application or service: business owner, users, authentication method, hosting location, inbound dependencies, outbound dependencies, and sensitivity of the data involved.

For devices, note whether they are managed, whether they meet baseline configuration, whether disk encryption is enabled, and whether they are compliant with your endpoint management platform. For services, note whether they are human-facing, machine-to-machine, or administrative.

Use data-flow diagrams and asset grouping to define trust boundaries

Once you have the inventory, group assets into trust zones. A common SME pattern is to separate user devices, admin devices, server workloads, management networks, and backup or recovery systems. In cloud environments, you may also separate production, development, and shared services. The point is to make trust boundaries explicit so that policy can be written around them.

Where possible, define boundaries around business functions rather than technical convenience. For example, finance systems, customer data platforms, and operational technology may deserve different treatment even if they sit on the same underlying network.

Design principles for ZTNA and microsegmentation

Good design is mostly about restraint. The more exceptions you allow, the more the model starts to resemble the flat network you were trying to leave behind. Three principles matter most: least privilege, default deny, and path separation.

Least privilege access by identity, device posture, and context

Access should be based on identity, device posture, and context. Identity tells you who is asking. Device posture tells you whether the device is managed and healthy. Context tells you whether the request is coming from the right place, at the right time, and with the right risk profile. Conditional access policies are useful here because they let you require multi-factor authentication, compliant devices, or step-up authentication for sensitive apps.

For service access, use workload identity where possible rather than shared credentials. Where service accounts are unavoidable, scope them tightly and monitor their use carefully. Avoid reusing the same account across environments.

Default deny between segments and explicit allow rules

Microsegmentation should default to deny. Then you add explicit allow rules for known dependencies. This is more work up front, but it gives you a defensible baseline. The main challenge is discovering the real dependencies without over-permitting. Start by observing traffic, then convert stable patterns into policy. Be careful not to encode temporary troubleshooting access as permanent policy.

In practice, this often means allowing only specific source and destination pairs, ports, and protocols. In cloud platforms, that may be expressed through security groups, network security groups, firewall rules, or host-based controls. In container or Kubernetes environments, network policies can provide a similar effect at the workload layer.

Separate administrative, user, and service-to-service paths

Administrative access should be treated as a separate trust path. Admins should use dedicated accounts, dedicated devices where feasible, and stronger controls than standard users. Service-to-service traffic should also be isolated from user traffic. A web application should not be able to use the same route or credentials as a human operator.

This separation reduces the chance that one compromise can be used to pivot into another trust domain. It also makes audit and investigation easier because the traffic patterns are more distinct.

Reference architecture options

There is no single reference architecture that fits every SME, but there are a few common patterns.

Identity-centric access with Microsoft Entra ID and conditional access

An identity-centric design is often the most practical starting point for organisations already using Microsoft 365. Entra ID can act as the policy decision point for user authentication and conditional access, while applications are published through a ZTNA or application access layer. This gives you central control over sign-in risk, device compliance, and session restrictions. If you are designing around Entra ID specifically, the article on Designing Zero Trust architectures with Entra ID is a useful companion.

For SMEs with mixed estates, the same pattern can still work if the identity provider is the control plane and the access layer supports SAML, OpenID Connect, or reverse proxy publishing. The important part is that policy is enforced before the application is reached.

Agent-based versus network-based segmentation approaches

Microsegmentation can be implemented with host agents, network controls, or a combination of both. Agent-based approaches are often more precise because they can see the workload context and enforce policy closer to the application. Network-based approaches can be easier to deploy in some legacy environments because they rely on infrastructure controls rather than software on every host.

For SMEs, the trade-off is usually between precision and operational simplicity. Agent-based controls can be excellent for modern servers and cloud workloads, but they require lifecycle management. Network-based controls may be easier to understand, but they can become coarse if the environment is not well structured. Many organisations end up with a hybrid model: network controls for broad zone separation and host or workload controls for critical assets.

How cloud, on-premises, and SaaS environments change the design

Cloud environments often give you more granular policy primitives, but they also create more places for policy to drift. On-premises environments may have older systems that cannot support modern agents or per-workload controls. SaaS applications reduce internal traffic, but they increase the importance of identity and session control because the application itself is outside your network boundary.

In a mixed environment, do not try to force one control pattern everywhere. Use the strongest practical control for each layer. For SaaS, focus on identity and device trust. For cloud workloads, focus on security groups, network policies, and workload identity. For legacy on-premises systems, use network zones and compensating controls where necessary.

Implementation approach without overengineering it

The safest way to start is with a narrow scope and a clear business outcome. Pick one high-value application or one business unit, then design the policy around that slice of the environment. This gives you something measurable without turning the project into a multi-year redesign.

Start with high-value assets and crown-jewel applications

Choose systems that would hurt most if compromised or unavailable. That may be finance, customer data, production systems, or remote administration tooling. Map the dependencies, define the trust zones, and decide what must be allowed for the application to function. Everything else should be denied or at least monitored during the pilot.

This approach also helps with stakeholder buy-in because the business value is obvious. You are not abstractly improving security. You are protecting a specific process that matters.

Pilot one business unit or one application stack first

A pilot should include real users, real traffic, and a rollback plan. Do not test only in a lab. Observe the traffic for a period, create the initial allow rules, and then tighten them gradually. Expect to uncover undocumented dependencies, especially around reporting, patching, monitoring, and backup jobs.

During the pilot, keep a close eye on helpdesk tickets, blocked connections, and application errors. These are often the first signs that a rule is too narrow or that a dependency was missed.

Expand policy coverage in phases

Once the pilot is stable, expand by zone or application family. A phased rollout is usually safer than a big-bang change because it lets you learn from each segment. Document what changed, why it changed, and who approved it. That documentation becomes important later when you need to review exceptions or explain the design to stakeholders.

Policy design and rule management

Policy design is where many segmentation efforts become messy. The challenge is not writing the first rule set. The challenge is keeping it understandable six months later.

Translating application dependencies into allow rules

Start from application dependency maps rather than from subnets. If an application needs HTTPS from a specific reverse proxy, allow that. If a database only accepts connections from one application host, allow that and nothing else. Avoid broad rules such as entire VLANs or any-to-any between zones unless there is a strong and documented reason.

Where possible, use labels, tags, or groups rather than static IP addresses. That makes policy more resilient when infrastructure changes. In cloud-native environments, this is often the difference between a maintainable policy and one that breaks every time a workload is redeployed.

Handling service accounts, automation, and privileged access

Automation is often the hidden source of segmentation exceptions. Backups, monitoring, configuration management, and deployment pipelines all need access, but they should have narrowly scoped permissions and predictable source locations. Use separate service identities for separate functions, and avoid sharing credentials between tools.

Privileged access should be time-bound where possible. Just-in-time elevation, approval workflows, and dedicated admin workstations all reduce the chance that a privileged session becomes a permanent foothold.

Avoiding rule sprawl and unmanaged exceptions

Rule sprawl happens when temporary exceptions are never removed. The result is a policy set that looks segmented on paper but behaves like a flat network in practice. Put an expiry date on exceptions, review them regularly, and assign ownership. If a rule cannot be explained in one sentence, it is probably too broad.

It is also worth keeping a change log for policy updates. When something breaks, you want to know whether the issue is a control failure, an application change, or a dependency that was never documented.

Operational visibility and validation

Segmentation is only useful if you can see whether it is working. That means collecting logs, flow data, and endpoint telemetry, then using them to validate policy and investigate anomalies. If you already have SIEM or XDR tooling, this is where it becomes valuable. A well-instrumented design should show both allowed and blocked attempts, especially around sensitive zones.

Using logs, flow data, and SIEM or XDR telemetry to validate policy

Look for repeated denied connections, unexpected east-west traffic, and access attempts outside normal hours or from unusual devices. These patterns may indicate misconfiguration, but they may also indicate reconnaissance or lateral movement. If you are building detections around this, the article on unified threat detection across endpoint, identity, and network is relevant.

For cloud environments, flow logs and security telemetry can help you confirm whether the policy matches the intended architecture. For on-premises environments, firewall logs, host firewall events, and authentication logs are often the best starting point.

Detecting blocked connections, misconfigurations, and unusual lateral movement

Blocked connections are not automatically bad. They are often the evidence you need to refine policy. The question is whether the block is expected. If a blocked connection is tied to a business process, you need to understand the dependency. If it is tied to a host that should never talk to that destination, it may be a useful signal.

Unusual lateral movement often shows up as a host reaching multiple internal systems it has never contacted before, or as a service account being used from a new source. These are the kinds of behaviours that segmentation can make easier to spot.

Testing changes safely before broad rollout

Before you enforce a new rule set broadly, test it in monitor mode or with a limited scope. Validate the change against representative traffic, then roll it out in stages. Keep a rollback path ready. In small organisations, a failed policy change can be as disruptive as the threat you were trying to reduce.

Common design mistakes and how to avoid them

One common mistake is treating segmentation as a one-time project. Networks change, applications change, and business processes change. If the policy is not reviewed, it will drift.

Another mistake is designing around the network only. Identity and device trust matter just as much as source and destination. If a policy allows any managed device to reach a sensitive application, you may still have too much trust.

A third mistake is ignoring legacy systems. Older applications may not support modern agents, mutual authentication, or fine-grained policy. In those cases, use compensating controls, isolate them carefully, and document the risk accepted by the business.

How to measure whether the design is working

Good metrics help you decide whether the design is reducing risk or just adding complexity. Useful measures include the number of reachable paths to crown-jewel assets, the number of exceptions in place, the time taken to approve and remove exceptions, and the number of blocked connections that turn out to be legitimate dependencies.

You can also measure containment. If a test account, compromised endpoint, or isolated workload cannot reach more than its intended zone, the design is doing its job. Over time, you should see fewer broad trust relationships and fewer systems that can talk to everything else.

Operationally, watch the change failure rate for segmentation updates. If every policy change causes outages, the design is too brittle. The goal is not perfect restriction. The goal is controlled, understandable, and maintainable restriction.

A pragmatic roadmap for UK SMEs

A sensible 90-day starter plan looks like this. First, identify one high-value application or one critical trust zone. Second, map its users, devices, dependencies, and administrative paths. Third, define the minimum access required and implement monitor mode or limited enforcement. Fourth, review logs and blocked traffic, then tighten the policy. Fifth, document the exceptions, ownership, and review cycle.

For governance, keep a simple record of the architecture decision, the trust boundaries, the policy rationale, and the rollback approach. That record is useful for internal review, future expansion, and alignment with broader security management work. If you are building this into a wider architecture practice, Applying TOGAF for security architecture design can help structure the decision-making, even if you do not use the framework in full.

Most SMEs do not need to solve everything at once. A focused design around one critical path is usually enough to prove value and build confidence for the next phase.

FAQs

Do we need both ZTNA and microsegmentation?

Not always, but they solve different problems. ZTNA controls who can reach an application and under what conditions. Microsegmentation controls what can move laterally once something is inside the environment. If your main risk is remote access and broad user connectivity, ZTNA may be the first priority. If your main risk is internal spread after compromise, microsegmentation becomes more important. Many SMEs benefit from both, but they do not have to be deployed at the same time.

What is the simplest way to start microsegmentation in a small organisation?

Start with one critical application stack and one clear trust boundary. Map the real dependencies, allow only the required traffic, and deny everything else by default. Use existing infrastructure controls where possible, such as firewall rules, security groups, or host firewalls. Keep the first scope small enough that you can understand and support it, then expand in phases.

If you would like help shaping the design, validating the trust model, or planning a phased rollout that fits your environment, Speak to a consultant.