Why Zero Trust Is the Way Forward — and How Todyl Can Help
For years, business cyber security was built around a relatively simple assumption:
Inside the company network = trusted.
Outside the company network = untrusted.
A firewall protected the office perimeter, employees connected to the internal network, and remote workers were brought “inside” through a VPN.
That model made considerably more sense when most:
employees worked in one office
applications ran on local servers
company information remained behind the firewall
devices rarely left the building
That is no longer how most organisations work.
Employees now access:
Microsoft 365
SaaS applications
cloud servers
remote desktops
branch networks
business systems
from:
offices
homes
hotels
customer sites
mobile connections
There is no longer one clear perimeter that can automatically be trusted.
That is why Zero Trust has become such an important security model.
Its central principle is simple:
Do not grant trust merely because somebody or something is already on the network. Verify access based on identity, device, context and policy.
The NCSC describes Zero Trust as an architectural approach in which the network itself is assumed hostile and individual requests are authorised according to policy.
Zero Trust Is Not a Product
This is the first point to get right.
You cannot simply buy:
“Zero Trust”
install it and declare the business secure.
Zero Trust is an approach to designing security.
The NCSC’s current principles include:
understanding users, devices, applications, services and data
establishing reliable identities
assessing device and service health
authorising requests through policy
authenticating and authorising throughout the environment
monitoring users, devices and services
treating every network—including the internal network—as potentially hostile.
That means Zero Trust involves more than remote access.
It can involve:
identity + MFA + devices + applications + network access + segmentation + monitoring + response.
Technology such as Todyl can help implement several of those controls.
But the architecture comes first.
Why the Traditional Network Perimeter Is No Longer Enough
Imagine a traditional office network.
An employee connects to the corporate LAN.
Once connected, their device can potentially discover:
servers
printers
workstations
management interfaces
network equipment
backup infrastructure
The employee may never intentionally access those systems.
But the network paths exist.
Now imagine their laptop is compromised by phishing.
Malware may be able to use those same routes to:
scan the network
discover systems
attack vulnerable services
reuse stolen credentials
move laterally
Zero Trust changes the assumption.
Instead of asking:
“Are you connected to our network?”
you ask:
“Who are you, what device are you using, what are you trying to access and should this request be allowed?”
Identity Becomes Central
A password alone should not automatically create broad trust.
Passwords can be:
phished
stolen by malware
reused
guessed
exposed in breaches
A stronger access decision may take several signals into account:
user identity
MFA
group membership
device condition
requested application
location
risk
The NCSC says Zero Trust authentication and authorisation should use multiple signals—including user identity, device health and location—and explicitly states that MFA is required within a Zero Trust architecture.
Where practical, the NCSC also recommends strong passwordless authentication such as FIDO2.
Least Privilege: Give People Only What They Need
Suppose a sales employee needs:
CRM
SharePoint
They probably do not need network access to:
finance server
backup infrastructure
hypervisor management
domain-controller administration
Traditional networks often provide connectivity simply because systems sit on the same LAN.
Zero Trust moves towards:
deny by default → explicitly allow what is required.
That can dramatically reduce an attacker’s options after compromising one account or endpoint.
The NCSC’s current guidance says each request should be authorised against policy and that access decisions should use multiple signals rather than implicit network trust.
Where Todyl Fits
Todyl provides a security platform that can support several parts of a Zero Trust architecture.
Its current platform includes capabilities around:
Secure Access Service Edge — SASE
Zero Trust Network Access — ZTNA
LAN ZeroTrust
secure web gateway
next-generation firewalling
secure DNS
web filtering
endpoint security
SIEM
MXDR
Todyl describes its SASE platform as an always-on cloud-delivered security and connectivity layer with identity-aware access policies and more than a dozen consolidated network-security capabilities.
The value is not simply having lots of features.
It is the ability to apply:
access + connectivity + security + monitoring
more consistently wherever employees are working.
ZTNA: Move Beyond Broad VPN Access
Traditional VPN access commonly works like this:
user authenticates → device joins corporate network.
That can give the remote computer considerably more network visibility than it actually requires.
Zero Trust Network Access changes that model.
Instead of:
“Connect this laptop to the network.”
the policy can become:
“Allow this verified user on this approved device to access this specific application.”
Todyl places ZTNA within its SASE platform and uses identity-based policy controls to restrict access to approved resources.
That can reduce:
exposed services
broad network visibility
lateral movement
complicated remote-access rules
But ZTNA should not simply become:
“our old VPN with a different name.”
The NCSC’s May 2026 guidance specifically warns against carrying old network-trust assumptions into a supposedly Zero Trust design.
Zero Trust Should Apply Inside the Office Too
Remote access is only half the problem.
Why should a laptop become inherently trustworthy simply because somebody carried it into the office and connected to Wi-Fi?
The NCSC’s principle is explicit:
do not trust any network, including your own.
Todyl addresses this through its LAN ZeroTrust capabilities, which it describes as providing deny-by-default segmentation between devices and resources.
That can help isolate areas such as:
workstations
servers
finance systems
printers
cameras
guest devices
management interfaces
backup infrastructure
The objective is to remove unnecessary communication paths.
Segmentation Limits the Blast Radius
Consider this attack:
1. An employee opens a convincing phishing message.
2. Their laptop is compromised.
3. Malware scans the network.
4. It discovers an exposed management service.
5. Stolen credentials provide further access.
6. The attacker reaches the servers or backups.
Network segmentation can interrupt that chain.
If the infected workstation has no legitimate reason to communicate directly with backup infrastructure, why allow that route at all?
The infected endpoint still needs investigation.
But the blast radius can be significantly smaller.
Protect Users Wherever They Work
One weakness of office-centric security is that protection can change when an employee leaves the building.
At 9am:
office firewall protecting traffic
At 2pm:
employee works from hotel Wi-Fi
A cloud-delivered SASE architecture can apply more consistent security policy regardless of where the user connects.
Todyl currently advertises capabilities including:
secure web gateway
secure DNS
firewalling
SSL inspection
content filtering
conditional access
through more than 40 global points of presence.
This can be particularly useful for hybrid organisations whose employees primarily use cloud services rather than applications sitting inside one head office.
Device Health Matters as Much as Identity
A user can be completely genuine while using a compromised laptop.
Imagine:
correct employee
correct MFA
but:
malware already controls the device.
Identity alone is not enough.
The NCSC specifically recommends using device and service health as signals when making Zero Trust access decisions.
That is why endpoint security still matters.
Todyl’s broader security platform combines its network-access capabilities with endpoint detection and response and managed detection capabilities.
Zero Trust does not replace endpoint security.
It works alongside it.
Monitoring Is Part of Zero Trust
A Zero Trust architecture should also generate useful information about:
users
devices
access requests
denied connections
unusual activity
The NCSC explicitly makes monitoring users, devices and services one of its Zero Trust design principles.
Todyl’s wider platform includes:
SIEM + MXDR
which can help connect events from multiple parts of the security environment.
For example:
unusual authentication
endpoint alert
suspicious DNS traffic
blocked lateral connection
may collectively tell a much more important story than any one alert on its own.
Secure DNS Adds Another Layer
Attackers rely on DNS just like legitimate applications do.
Malware may attempt to resolve domains used for:
command and control
phishing
malicious downloads
data exfiltration
Todyl includes Secure DNS within its SASE offering and can apply DNS policies based on factors including users, devices and location.
That can prevent some malicious connections before the destination is ever reached.
But DNS security is one layer.
It does not replace:
endpoint security
MFA
email protection
staff awareness
Security Consolidation Can Help—But It Is Not Automatically Better
Businesses often accumulate:
VPN
firewall
antivirus
DNS filtering
web filtering
SIEM
threat detection
from several suppliers.
That can produce:
multiple portals
inconsistent policies
duplicated capability
fragmented alerts
Todyl’s proposition is partly about consolidating those functions into a smaller number of integrated platform components.
That can make management simpler.
But consolidation should never be the objective on its own.
A single badly configured platform is not safer merely because it replaced six consoles.
The question should be:
Does the architecture actually reduce risk and improve visibility?
Do Not Replace One Trusted Perimeter With Another
This is an important 2026 lesson.
A poorly designed ZTNA implementation can accidentally recreate the same problem it was intended to solve.
For example:
Authenticate once → gain broad network access indefinitely.
That is still essentially perimeter trust.
The NCSC’s latest ZTNA guidance says policy engines should use meaningful signals and access should be designed around the actual users, devices and applications involved.
A good Zero Trust implementation continually asks whether the access is still appropriate.
Don't Begin With the Product
This is probably the most important change I would make to the original article.
Before deploying Todyl—or any other Zero Trust technology—identify:
users
devices
applications
services
sensitive data
existing access paths
legacy systems
remote-working requirements
Then ask:
Who genuinely needs access to what?
The NCSC’s first Zero Trust principle is knowing your architecture, because otherwise organisations risk carrying existing vulnerabilities and poor trust relationships into the new design.
Technology should implement your access model.
It should not define it for you.
Zero Trust Does Not Mean Distrusting Employees
The phrase sometimes sounds adversarial.
It does not mean:
“We think every employee is malicious.”
It means security decisions should not depend on assumptions such as:
“The device is inside the office, therefore it must be safe.”
A legitimate employee with a compromised device is still a security risk.
A malicious connection using stolen legitimate credentials is still malicious.
Zero Trust removes unnecessary assumptions.
A Practical Zero Trust Journey for an SME
I would approach it in this order:
1. Understand the environment
Identify:
people
devices
applications
data
dependencies
2. Strengthen identity
Deploy:
MFA
strong authentication
sensible privileged access
3. Manage endpoints
Know whether devices are:
patched
protected
compliant
4. Map required access
Define which users and devices genuinely need which resources.
5. Introduce segmentation and ZTNA
Replace broad connectivity with explicit access.
6. Apply consistent internet security
Protect office and remote users.
7. Monitor continuously
Connect identity, network and endpoint events.
8. Review and refine
Zero Trust is not a one-time migration project.
It should evolve as the business changes.
That approach aligns closely with the NCSC’s current advice to introduce Zero Trust deliberately and incrementally rather than treating ZTNA as an isolated technology deployment.
Is Todyl Right for Every Business?
No security platform is automatically right for every organisation.
Todyl may be attractive where a business wants to consolidate:
secure connectivity
ZTNA
segmentation
internet security
endpoint security
monitoring
managed response
into a more integrated architecture.
But selection should still consider:
existing infrastructure
Microsoft 365/identity environment
applications
device estate
compliance requirements
existing security tooling
budget
operational requirements
The NCSC specifically recommends testing ZTNA services against realistic users, devices and applications before committing to a design.
That is exactly how I would approach it.
How Hamilton Group Can Help
Hamilton Group can help businesses move towards Zero Trust without turning it into an unnecessarily complicated technology project.
We can help with:
Zero Trust strategy
Todyl
SASE
Zero Trust Network Access
network segmentation
endpoint security
secure DNS
Microsoft 365 security
MFA
security monitoring
MXDR
cyber-security reviews
The objective is not to buy a product carrying a Zero Trust label.
It is to build an environment where:
identity is verified, devices are assessed, access is limited, networks are not inherently trusted and suspicious behaviour can be detected quickly.
Todyl can provide several of the technologies needed to implement that model, while Hamilton Group can help design, deploy and manage them around the needs of the business.
Visit hgmssp.com or call 0330 043 0069 to discuss Zero Trust, Todyl and business cyber security.