Zero Trust is a cybersecurity approach based on the principle of never automatically trusting a user, device, application, or network connection simply because it is inside a corporate network. Instead, access decisions are based on identity, device health, resource sensitivity, policy, and other relevant signals. Implementing Zero Trust requires strong identity controls, least-privilege access, continuous monitoring, and a phased approach to modernising security architecture.
For many years, organisations relied on a familiar security model: establish a trusted internal network, protect its boundaries with firewalls, and allow users inside that boundary to access internal resources.
This approach worked reasonably well when most employees worked from offices, applications ran in corporate data centres, and devices rarely left the organisation's network.
Modern environments are very different.
Employees work remotely, applications run across multiple cloud platforms, contractors connect from external networks, and business data moves between endpoints, SaaS applications, and infrastructure operated by third parties.
An attacker who compromises one employee's account may attempt to access email, collaboration platforms, internal applications, or sensitive cloud resources. If internal access controls are weak, the initial compromise can become a much larger incident.
This is the problem Zero Trust is designed to address.
Rather than assuming that a connection is trustworthy because it originates from an internal network, Zero Trust requires access to be explicitly authorised and appropriately restricted.
The central principle is simple: trust should not be granted automatically based on network location.
Zero Trust is a security model in which access to resources is controlled through explicit, context-aware decisions rather than implicit trust.
It applies to users, devices, workloads, applications, APIs, and other identities that request access to organisational resources.
The model is commonly associated with three principles:
Verify explicitly: Evaluate relevant identity, device, resource, and contextual signals before granting access.
Use least-privilege access: Give each identity only the permissions required for its task.
Assume breach: Design controls and monitoring on the assumption that an attacker may already have gained access somewhere in the environment.
Zero Trust does not mean that every request must always trigger a manual approval or that users should be repeatedly prompted to sign in. Policies can make automated decisions based on risk and context.
It also does not require the elimination of all network perimeters. Firewalls, VPNs, and network segmentation may remain useful, but they are not sufficient on their own to establish trust.
Zero Trust is an architectural approach rather than a single product. It combines identity, device, access, network, application, data, and monitoring controls.
<AsyncImage query="professional Zero Trust security architecture diagram users devices policy engine policy administrator protected resources applications data identity" aspectRatio="16:9" width="100%" />
Identity is central to Zero Trust because every access request needs an accountable identity or workload context.
Identity and Access Management (IAM) controls establish who or what is requesting access and which permissions should apply.
Important capabilities include:
Multi-factor authentication (MFA).
Single sign-on (SSO).
Role-based or attribute-based access control.
Privileged Access Management (PAM).
Lifecycle management for employee and contractor accounts.
Conditional access policies.
For example, a user who successfully authenticates may still be denied access to a highly sensitive application if the request violates an access policy.
A valid user identity does not guarantee that the device is safe.
An organisation may require devices to meet specific conditions before they can access sensitive resources. These conditions may include supported operating-system versions, security updates, disk encryption, endpoint protection, and device-management compliance.
Endpoint Detection and Response (EDR) and Mobile Device Management (MDM) solutions can provide relevant security or compliance signals, depending on their integration.
A non-compliant device may be blocked, restricted to limited resources, or required to complete remediation before access is granted.
A Zero Trust architecture needs a way to evaluate requests and enforce the resulting decisions.
NIST Special Publication 800-207 describes core architectural components that include the Policy Engine (PE), Policy Administrator (PA), and Policy Enforcement Point (PEP).
Policy Engine: Makes the access decision based on policy and available information.
Policy Administrator: Helps establish, manage, and communicate the decision that should be enforced.
Policy Enforcement Point: Enables, monitors, or terminates the connection to the protected resource according to the decision.
The exact implementation varies by product and deployment model, but the overall objective is to separate policy decisions from the enforcement of those decisions.
Zero Trust reduces unnecessary access between systems. Instead of allowing broad access to an entire internal network, organisations can restrict connectivity to specific applications, services, and resources.
Microsegmentation can create more granular boundaries around workloads or applications.
For example, a compromised employee laptop should not automatically be able to connect to production databases merely because both devices are connected to the corporate network.
Network controls can restrict communication to approved paths, while identity and application policies determine whether a particular request is authorised.
Zero Trust is not only about deciding who can connect to a system. It also involves protecting the data that system contains.
Data-focused controls may include:
Data classification and sensitivity labels.
Encryption at rest and in transit.
Data Loss Prevention (DLP).
Restrictions on downloads, copying, or external sharing.
Access controls based on business roles and resource sensitivity.
Auditing of access to sensitive information.
The aim is to ensure that access permissions reflect the sensitivity of the data, not simply the user's ability to authenticate.
Zero Trust relies on relevant information to evaluate access and detect changes in risk.
Security teams may correlate identity-provider logs, endpoint telemetry, network activity, cloud audit events, and application access records.
Signals such as unusual sign-ins, device compliance changes, unexpected privilege use, and suspicious data access may trigger additional verification, restricted access, or investigation.
Continuous monitoring does not mean every request is necessarily re-authenticated. It means that relevant signals and policy changes can influence access decisions and incident response throughout a session.
Consider an employee attempting to access a sensitive finance application from a laptop.
A simplified access decision may involve the following steps:
Access request: The user requests access to the application.
Identity verification: The identity provider evaluates the user's authentication and MFA status.
Device evaluation: The system checks available device identity and compliance information.
Context evaluation: The policy considers relevant factors such as resource sensitivity, location signals, session risk, and access conditions.
Policy decision: The request is approved, denied, or subjected to additional requirements.
Enforcement: The relevant enforcement point applies the decision.
Monitoring: Subsequent activity is monitored, and changing risk signals may prompt reassessment or response.
A simplified policy could require MFA, a managed and compliant device, and an approved role before granting access to sensitive financial records.
The exact conditions should depend on business needs, risk, and the reliability of the available signals.
Important: Zero Trust does not guarantee that every authorised session is safe. An attacker using a compromised account and a trusted device may still evade some controls. Strong monitoring, privilege restrictions, and incident response remain essential.
Zero Trust implementation should be phased. Attempting to redesign every identity, application, network, and data control at once can create operational disruption without delivering immediate, measurable security improvements.
Begin by identifying what needs protection and who or what can access it.
Build an inventory of:
Employee, contractor, service, and workload identities.
Endpoints and their management status.
Critical applications and cloud services.
Sensitive data repositories.
Privileged accounts.
Existing authentication and network access paths.
Prioritise resources based on business impact, sensitivity, exposure, and existing security weaknesses.
An incomplete inventory can undermine later policy decisions because unknown applications, unmanaged devices, and overlooked service accounts may remain outside the intended controls.
Identity is often a practical starting point because compromised accounts are frequently involved in security incidents.
Recommended actions include:
Enforce MFA, prioritising privileged and high-risk accounts.
Prefer phishing-resistant authentication for privileged users and other high-risk scenarios where feasible.
Remove unnecessary permissions.
Review dormant and orphaned accounts.
Introduce privileged access controls.
Improve joiner, mover, and leaver processes.
Protect service accounts and workload identities.
Organisations should also monitor unusual sign-ins, changes to authentication methods, unexpected privilege assignments, and suspicious consent or application-permission grants.
Determine which devices can access sensitive resources and what compliance requirements apply.
Integrate endpoint management and security telemetry where appropriate. Define how unmanaged, outdated, or compromised devices should be handled.
Possible responses include blocking access, restricting the user to lower-risk resources, or requiring remediation.
Create exception processes for business-critical situations, but ensure exceptions are approved, documented, time-limited where possible, and reviewed regularly.
Develop policies that consider identity, device status, application sensitivity, and other relevant risk signals.
For example:
Require stronger authentication for privileged access.
Restrict sensitive applications to approved managed devices.
Limit access from identities that do not need a particular resource.
Require additional verification for higher-risk requests.
Block access when required security conditions are not met.
Start with a limited pilot and observe the impact before enforcing policies across the entire organisation.
Reduce broad internal access and define which systems genuinely need to communicate.
Prioritise critical systems, administrative interfaces, and sensitive workloads. Restrict access between user endpoints, application servers, management systems, and databases according to documented requirements.
Where feasible, use identity-aware access controls or application-specific access mechanisms instead of granting broad network connectivity.
Before enforcing segmentation, map legitimate dependencies to avoid interrupting production services.
Classify important data and identify how users, applications, and workloads access it.
Apply appropriate controls for sensitive information, including encryption, access restrictions, external-sharing policies, and audit logging.
For cloud environments, review permissions, public exposure, workload identities, administrative roles, and security-policy changes.
Zero Trust should cover both human users and non-human identities such as applications, services, and automated workloads.
Centralise relevant telemetry in a SIEM or another suitable analytics platform.
Correlate identity events with endpoint, network, application, and cloud audit records. Create detections for suspicious access patterns, unusual privilege changes, policy tampering, and unexpected data access.
Define response procedures for scenarios such as:
A user account is suspected of compromise.
An endpoint becomes non-compliant or is identified as infected.
A privileged identity behaves unexpectedly.
A workload identity accesses resources outside its expected scope.
Responses may include revoking sessions, disabling accounts, isolating endpoints, restricting resource access, or initiating incident investigation.
Zero Trust is an ongoing programme, not a one-time deployment.
Review policy effectiveness, security incidents, access exceptions, user friction, and gaps in asset coverage. Update policies as applications, business processes, and threats change.
Useful measurements include MFA coverage, privileged-account coverage, managed-device coverage, time to revoke compromised access, and the number of critical resources protected by least-privilege controls.
Metrics should demonstrate actual risk reduction rather than simply count deployed products.
Imagine an attacker obtains an employee's credentials through a phishing attack.
In a traditional environment, a successful login might provide access to multiple internal resources, particularly if network access is broad and permissions are excessive.
In a well-designed Zero Trust environment, several independent controls may limit the attack.
Scenario timeline
StagePotential Zero Trust controlAttacker attempts to sign inMFA and identity-risk evaluationSign-in originates from an unfamiliar or risky contextConditional access and additional verificationAccess is attempted from an unmanaged deviceDevice-compliance policyAttacker tries to access a sensitive applicationApplication-specific authorisationAttacker attempts to reach a databaseLeast privilege and network segmentationSuspicious activity continues after accessIdentity, endpoint, and application monitoringAccount compromise is confirmedSession revocation, account containment, and investigationThese controls can reduce the likelihood and scope of a successful attack, but their effectiveness depends on implementation and configuration.
For instance, an attacker may steal an active session token, compromise a compliant device, or exploit an application vulnerability. Zero Trust must therefore be combined with endpoint security, secure application design, strong session protection, and incident response.
Older applications may rely on traditional network trust, shared accounts, or authentication methods that do not integrate easily with modern identity platforms.
Approach: Inventory dependencies, prioritise high-risk systems, and introduce compensating controls while modernisation is planned.
Organisations may operate several identity providers, directories, cloud platforms, and account-lifecycle processes. Inconsistent policies can create gaps.
Approach: Establish clear identity ownership, consolidate controls where practical, and standardise privileged-access and lifecycle procedures.
Poorly designed access policies can create repeated authentication prompts, block legitimate work, or disrupt business-critical applications.
Approach: Pilot changes, analyse sign-in failures, use risk-appropriate authentication, and maintain controlled exception processes.
Unknown devices, undocumented applications, and forgotten service accounts can remain outside enforcement and monitoring.
Approach: Maintain accurate asset and identity inventories, assign owners, and monitor for newly discovered or unmanaged resources.
An organisation may deploy MFA and conditional access while leaving users with unnecessary access to applications and data.
Approach: Review effective permissions, use least-privilege roles, remove stale grants, and periodically recertify access.
Different platforms may interpret device compliance, identity risk, and access conditions differently. Policy changes can also have unintended consequences.
Approach: Document policy intent, use staged rollouts, test dependencies, and define ownership for policy changes and troubleshooting.
Zero Trust can involve investments in identity management, endpoint security, network controls, logging, and application modernisation.
Approach: Start with the highest-risk identities and resources, reuse existing capabilities where appropriate, and build a phased roadmap tied to measurable outcomes.
Zero Trust controls can generate valuable telemetry for security operations.
SOC analysts may investigate:
Repeated MFA failures or suspicious authentication changes.
Sign-ins that violate conditional access policies.
Privilege escalation or unexpected role assignments.
Attempts to access resources outside an identity's normal scope.
Device-compliance changes before sensitive application access.
Unusual cloud permissions or workload-identity activity.
Attempts to modify security policies or weaken logging.
Consider a user who signs in successfully and then accesses a sensitive cloud resource that they have never used before.
The sign-in may be legitimate, but the access pattern may warrant further review. Analysts should correlate the identity event with device information, historical access patterns, application logs, and subsequent actions before determining whether the activity is malicious.
Zero Trust and the SOC serve complementary purposes: access policies reduce unnecessary exposure, while monitoring and investigation help identify suspicious activity that passes through those controls.
These are broad architectural differences, not absolute descriptions of every organisation. Traditional network controls remain useful, and modern Zero Trust architectures frequently incorporate firewalls, VPNs, and segmentation.
The important distinction is that network location alone is not sufficient evidence that an access request should be trusted.
Organisations should use established guidance when designing a Zero Trust programme.
NIST SP 800-207: Defines Zero Trust Architecture concepts, logical components, and deployment considerations.
CISA Zero Trust Maturity Model: Provides a maturity-oriented approach to improving capabilities across security domains.
NIST Cybersecurity Framework: Helps organisations manage cybersecurity risk and align security improvements with broader governance and operational objectives.
These resources support architecture and programme planning, but they do not replace organisation-specific risk assessment, testing, and implementation decisions.
Zero Trust changes the way organisations make access decisions. Instead of assuming that a user or device is trustworthy because it is connected to an internal network, it applies explicit, resource-focused policies informed by identity, device condition, permissions, and relevant risk signals.
Implementing Zero Trust requires more than deploying an identity platform or purchasing a security product. It involves discovering assets, strengthening authentication, reducing unnecessary permissions, segmenting critical resources, protecting data, and integrating monitoring with incident response.
The most effective programmes start with high-risk identities and resources, introduce controls in manageable phases, and continuously evaluate whether those controls reduce exposure without creating unacceptable operational disruption.
Zero Trust does not eliminate cyberattacks. It helps organisations limit implicit trust, reduce opportunities for lateral movement, and contain the potential impact when an attacker gains an initial foothold.
Further Reading
NIST SP 800-207: Zero Trust Architecture
CISA Zero Trust Maturity Model
NIST Cybersecurity Framework
MITRE ATT&CK — Adversary tactics and techniques.
Continue reading
Security & Defense
Active Directory (AD) is a central identity and access management service in many Windows enterprise environments. Because it controls authentication, group membership, permissions...
Security & Defense
Command-and-control (C2) traffic enables attackers to communicate with compromised systems, issue commands, retrieve information, and deliver additional payloads. Organisations det...
Security & Defense
Endpoint Detection and Response (EDR) solutions monitor endpoint activity, analyse suspicious behaviour, detect potential cyberattacks, and support rapid incident response. By corr...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
