Zero Trust Security: What It Actually Requires and How to Test It

Zero Trust is not a product you can buy. It is an architecture that only works if every control is implemented and tested.

Zero Trust is an architecture principle, not a product. It means that no user, device or network connection is trusted by default, regardless of whether it is inside or outside the corporate perimeter. Every access request must be authenticated, authorised and continuously validated.

This article explains what Zero Trust actually requires, how it maps to NIS2 obligations and how penetration testing reveals whether the controls your organisation has built are working the way they are supposed to.

TL;DR

Zero Trust is an architecture principle: no user, device or connection is trusted by default. It requires explicit verification of every access request, least privilege access for every identity and an assume-breach design across the environment. In practice it needs strong identity, microsegmentation, privileged access management and continuous monitoring. Internal network pentesting and red team exercises are the most reliable way to verify whether the architecture works as intended.

Why the perimeter model failed

Traditional network security was built on a trust boundary: the corporate network perimeter. Devices inside the perimeter were trusted. Devices outside were not. This model worked when employees worked from a fixed office, applications ran on corporate servers and the network boundary was clearly defined.

That model no longer describes how organisations operate. Remote work has dissolved the perimeter. Cloud applications have moved resources outside the corporate network. SaaS tools have distributed data across dozens of third-party providers. Mobile devices access corporate resources from untrusted networks. Contractors and partners need access to internal systems.

In this environment, an attacker who compromises a single device, account or access credential inside the perimeter has access to everything the network trusts. The perimeter assumption becomes the attacker's advantage.

The core principles of Zero Trust

Verify explicitly

Every access request must be authenticated and authorised using all available data: user identity, device health, location, service or workload, data classification and any anomalies in the request context. Network location is not a sufficient basis for trust. A device on the corporate LAN is not automatically trusted any more than a device connecting from a home network.

Use least privilege access

Every user, device and service should only have access to the specific resources it needs to perform its function, for the minimum time necessary. This limits the blast radius of any compromise. An attacker who gains access to a low-privilege account should not be able to reach critical systems without an additional privilege escalation step that can be detected and blocked.

Assume breach

Assume that attackers are already inside your environment. Design controls to minimise lateral movement, detect unusual access patterns quickly, limit the damage a compromised account or device can cause and enable rapid investigation and containment when a breach occurs. This assumption drives logging, monitoring, microsegmentation and incident response readiness.

Zero Trust and NIS2

Under NIS2 Article 21, essential and important entities must implement risk management measures across a defined set of security domains. Zero Trust architecture directly addresses several of these.

Access control. NIS2 requires documented access control policies. Zero Trust enforces granular, identity-based access control that is directly auditable and documentable.

Network security. NIS2 requires network and information system security measures. Zero Trust microsegmentation limits lateral movement and contains the impact of a breach.

Monitoring and detection. NIS2 requires continuous monitoring. Zero Trust architecture generates rich access logs across every resource request, providing the data needed for behavioural anomaly detection and incident investigation.

Incident response. NIS2 requires a tested incident response capability. Zero Trust architecture, through the assumption of breach principle, is designed to support rapid detection and containment, which are the first requirements of an effective incident response.

What Zero Trust actually requires in practice

Identity verification on every access request. Multi-factor authentication is the baseline, ideally phishing-resistant such as FIDO2 or passkeys. Strong identity management includes conditional access policies, device compliance checks and risk-based authentication that can step up requirements when anomalies are detected.

Microsegmentation. Divide the network and application environment into small segments with explicit access rules between them. A compromise in one segment should not automatically grant access to others. This applies to workloads, data stores, applications and communication paths.

Privileged access management. Privileged accounts must be strictly controlled. Administrative access should be just-in-time and just-enough, requiring approval for each access session rather than granting persistent administrative privileges.

Continuous monitoring. Log all access requests, all resource interactions and all authentication events. Use this data to detect anomalous behaviour. A user logging in from an unusual location at an unusual time and accessing unusual resources should trigger an alert, not proceed silently.

How penetration testing validates Zero Trust

Zero Trust is a design intent. Penetration testing determines whether the implementation matches that intent. Common findings in environments that claim Zero Trust architecture include overly broad network access rules that undermine microsegmentation, service accounts with excessive privileges that provide lateral movement paths, MFA configured for user-facing applications but missing on administrative interfaces and monitoring that logs access events but does not generate alerts for anomalous patterns.

The gap between declared architecture and implemented architecture is where attackers operate. A penetration test conducted from the assumption of breach perspective, starting from a compromised low-privilege account, reveals what an attacker can actually reach and how far they can move.

Frequently asked questions about Zero Trust

What is Zero Trust security?

Zero Trust is a security architecture principle based on the premise that no user, device or network connection should be trusted by default, regardless of location. Every access request must be verified using identity, device health and context. Access is granted at the minimum level required, for the minimum time required. The architecture assumes breach: controls are designed to limit lateral movement, detect anomalies and contain damage if a component is compromised.

Is Zero Trust a product or a framework?

Zero Trust is a framework and a set of architecture principles, not a single product. Many vendors sell products that support Zero Trust implementation, including identity providers, endpoint management tools, network access control solutions and security information and event management platforms. Implementing Zero Trust requires a combination of these tools governed by a consistent policy, not the purchase of any single product.

How does Zero Trust relate to NIS2 compliance?

Zero Trust architecture directly supports NIS2 compliance in several domains: access control, network security, monitoring and detection and incident response. Organisations implementing Zero Trust architecture generate the continuous monitoring logs, access control documentation and network segmentation evidence that NIS2 audits require. Zero Trust is not a compliance requirement in itself, but a well-implemented Zero Trust architecture significantly simplifies NIS2 compliance documentation.

What is microsegmentation in a Zero Trust context?

Microsegmentation divides the network and application environment into small, isolated segments with explicit access rules governing what can communicate with what. Unlike traditional network segmentation that creates a few large zones, microsegmentation creates many small zones down to the individual workload or application level. This limits lateral movement: an attacker who compromises one workload cannot automatically reach others without traversing an explicit access control boundary that can be monitored and blocked.

How does a penetration test assess Zero Trust architecture?

A penetration test assesses Zero Trust architecture by testing whether the implemented controls match the architecture's intent. The tester typically starts from a compromised credential or device, simulating the assumption-of-breach scenario, and attempts to move laterally through the environment. The test identifies where access rules are broader than intended, where MFA is missing on specific interfaces, where privileged accounts have persistent access that should be just-in-time and where monitoring would fail to detect the attacker's activity.

Related services and resources

Sectricity conducts internal network penetration testing and red team exercises that test whether Zero Trust architecture is implemented as intended. For cloud-native Zero Trust environments, pair with a cloud security assessment. For related guidance, see our guides on NIS2 compliance and incident response planning. Start with a free security scan.