What Is Zero Trust?
Zero trust is a security model built on a fundamental principle: never trust, always verify. Unlike traditional perimeter-based security, which assumes that everything inside the corporate network is trustworthy, zero trust treats every access request as potentially hostile, regardless of where it originates or what credentials are presented.
The concept was first articulated by Forrester Research analyst John Kindervag in 2010, but it has gained enormous momentum in recent years as organisations grapple with the collapse of the traditional network perimeter. Cloud adoption, remote work, BYOD policies, and increasingly sophisticated adversaries have rendered the castle-and-moat security model obsolete. Zero trust provides a framework for securing modern environments where the perimeter is everywhere and nowhere.
The Core Principles of Zero Trust
While zero trust implementations vary, the model is built on several foundational principles that are consistent across frameworks and vendors:
1. Verify Explicitly
Every access request must be authenticated and authorised based on all available data points, including user identity, device health, location, service or workload, data classification, and anomalies. This is a departure from traditional models that grant broad access based on a single authentication event (e.g., logging into the VPN).
2. Use Least-Privilege Access
Users and systems should receive only the minimum level of access required to perform their function, and only for the duration needed. This includes:
- Just-in-time (JIT) access: Granting elevated privileges on demand and revoking them automatically after a defined period.
- Just-enough-access (JEA): Scoping access to specific resources and actions rather than granting broad administrative roles.
- Risk-based adaptive policies: Dynamically adjusting access levels based on real-time risk signals. A user accessing a low-sensitivity application from a managed device on the corporate network may receive smooth access, while the same user accessing a high-sensitivity application from an unmanaged device in an unusual location may be challenged with additional authentication or denied entirely.
3. Assume Breach
Zero trust operates on the assumption that adversaries are already present in the environment. This assumption drives several critical design decisions:
- Micro-segmentation: Dividing the network into fine-grained segments to limit the blast radius of any single compromise.
- End-to-end encryption: Encrypting data in transit even within the internal network, eliminating the assumption that internal traffic is safe.
- Continuous monitoring and validation: Verifying trust continuously throughout a session, not just at the point of initial authentication.
The NIST Zero Trust Architecture Framework
The National Institute of Standards and Technology (NIST) published Special Publication 800-207, "Zero Trust Architecture," which has become the de facto reference framework for zero trust implementations. The NIST framework defines the logical components of a zero trust architecture:
Policy Engine (PE)
The policy engine is the brain of the zero trust architecture. It makes access decisions based on enterprise policy, informed by inputs from multiple sources including identity stores, threat intelligence, activity logs, and data classification. The PE evaluates each access request against a set of rules and produces an allow or deny decision.
Policy Administrator (PA)
The policy administrator is responsible for establishing and terminating communication paths based on the PE's decisions. It instructs the policy enforcement points to open or close connections. The PA also generates session-specific credentials or tokens that grant access to the requested resource.
Policy Enforcement Point (PEP)
The policy enforcement point is the gatekeeper that sits between the subject (user, device, or application) and the resource. It enables, monitors, and terminates connections based on instructions from the PA. PEPs can take many forms: network gateways, application proxies, host-based firewalls, or API gateways.
Data Sources
The PE makes informed decisions by consuming data from multiple sources:
- Identity management: User identities, roles, group memberships, and authentication status.
- Device inventory and compliance: Device health, patch level, encryption status, and compliance with security policies.
- Threat intelligence: Known indicators of compromise, attacker infrastructure, and active threat campaigns.
- Activity logs: Historical and real-time data about user and entity behaviour, including authentication logs, access patterns, and anomaly scores.
- Data classification: The sensitivity level of the resource being accessed.
Implementing Zero Trust: A Practical Roadmap
Zero trust is not a product you can purchase; it is an architectural transformation that unfolds over months and years. The following roadmap provides a pragmatic implementation path:
Phase 1: Establish Visibility and Identity Foundation
You cannot protect what you cannot see, and you cannot enforce policy without knowing who is making each request.
- Asset discovery and inventory: Catalogue all users, devices, applications, and data stores across on-premises and cloud environments. This is the foundation upon which all zero trust policies will be built.
- Identity consolidation: Implement a centralised identity provider (IdP) that serves as the authoritative source of identity for all access decisions. Federate with partner and cloud-service identities where necessary.
- Multi-factor authentication: Enforce MFA for all users across all applications. This is the single most impactful step in a zero trust journey and should be prioritised above all others.
- Device inventory and health assessment: Deploy device-management and compliance tools that can assess the security posture of every device requesting access, managed and unmanaged.
Phase 2: Implement Micro-Segmentation and Access Controls
With visibility and identity established, begin enforcing granular access policies:
- Network micro-segmentation: Implement software-defined segmentation that isolates workloads based on function, sensitivity, and trust level. Start with the most sensitive assets (financial systems, customer databases, intellectual property repositories) and expand progressively.
- Application-level access control: Deploy zero trust network access (ZTNA) solutions that broker access to individual applications rather than granting broad network access via VPN. ZTNA ensures that users can reach only the specific applications they are authorised to use.
- Conditional access policies: Define risk-based policies that consider user identity, device compliance, location, and application sensitivity when making access decisions. High-risk scenarios (unmanaged device, unusual location, sensitive application) should trigger additional verification or access restrictions.
Phase 3: Deploy Continuous Monitoring and Analytics
Zero trust requires ongoing verification, not just point-in-time authentication:
- User and entity behaviour analytics (UEBA): Deploy behavioural-analytics capabilities that build baselines for every user and device and detect deviations that may indicate compromise or insider threat.
- Network traffic analysis: Monitor east-west network traffic for anomalous communication patterns that could indicate lateral movement by an attacker who has bypassed access controls.
- Endpoint detection and response: Ensure that every endpoint is instrumented with an agent that provides continuous visibility into process activity, file operations, and network connections.
- Unified security monitoring: Consolidate security telemetry from all sources (identity, endpoint, network, cloud) into a unified analytics platform that can correlate signals across domains.
Phase 4: Automate Response and Continuously Improve
Mature zero trust architectures incorporate automated response and continuous refinement:
- Automated containment: When anomalous behaviour is detected, automatically adjust access policies (revoke sessions, require re-authentication, restrict access scope, or isolate the device) without waiting for human intervention.
- Policy refinement: Use analytics data to continuously refine access policies, removing unnecessary permissions and tightening controls based on actual usage patterns.
- Regular posture assessment: Conduct periodic zero trust maturity assessments to identify gaps and prioritise improvements.
The Identity-Centric Approach
At the heart of zero trust is identity. In a world without a meaningful network perimeter, identity becomes the primary control plane. Every access decision, whether a user accessing an application, a workload communicating with an API, or a device connecting to the network, is an identity decision.
This identity-centric approach has several implications:
- Identity must be strong: Passwords alone are insufficient. MFA, certificate-based authentication, and increasingly passwordless methods (FIDO2, passkeys) are essential to establish trustworthy identity.
- Identity must be continuous: Authentication is not a one-time event. Continuous evaluation of session risk, based on user behaviour, device posture, and environmental signals, must occur throughout the session.
- Identity must be universal: The same identity framework must span on-premises applications, cloud services, APIs, and machine-to-machine communications. Fragmented identity creates gaps that adversaries exploit.
Where SenseOn Fits in Zero Trust Architecture
SenseOn provides the continuous monitoring and analytics layer that zero trust architectures depend on. Specifically:
- Unified telemetry for continuous verification: SenseOn's single agent captures endpoint, network, and identity telemetry from every monitored device. This telemetry feeds the behavioural baselines and anomaly detection that zero trust requires for continuous session evaluation.
- Behavioural analytics across all domains: The cross-domain correlation engine analyses user behaviour, device activity, and network communications in parallel, detecting deviations that may indicate compromised credentials, insider threats, or lateral movement.
- Automated response integration: When SenseOn detects high-confidence threats, automated response actions (endpoint isolation, process termination, session revocation) can be triggered immediately, aligning with the assume-breach principle of zero trust.
- Micro-segmentation validation: SenseOn's network visibility enables organisations to verify that micro-segmentation policies are effective by monitoring for traffic that crosses segment boundaries outside of defined policies.
Common Zero Trust Pitfalls
Organisations embarking on a zero trust journey should be aware of common pitfalls:
- Treating zero trust as a product: Zero trust is an architectural strategy, not a single technology. No vendor can deliver "zero trust in a box." Be wary of vendors who claim otherwise.
- Boiling the ocean: Attempting to implement zero trust across the entire environment simultaneously is a recipe for failure. Start with the highest-value, highest-risk assets and expand progressively.
- Neglecting user experience: Zero trust policies that create excessive friction for users will be circumvented. Balance security with usability through risk-adaptive policies that apply strong controls only when warranted.
- Forgetting operational technology (OT): Many zero trust programmes focus exclusively on IT environments and neglect OT, IoT, and legacy systems that may not support modern authentication and segmentation mechanisms.
- Underinvesting in visibility: Zero trust policies are only as effective as the visibility that informs them. Organisations that implement access controls without investing in continuous monitoring are building on an incomplete foundation.
Zero trust is not a destination; it is a continuous journey of improving security posture through better visibility, stronger identity controls, finer-grained access policies, and smarter analytics. The organisations that embrace this journey will be far better positioned to withstand the threats of 2025 and beyond.
Related reading:
