Developers must design and operate systems that are built on the tenet of zero trust.
In early 2024, the ‘Midnight Blizzard’ attack proved that even tech giants are vulnerable when they rely on implicit trust; hackers compromised a single legacy test account and used it to move laterally, eventually accessing Microsoft’s internal corporate emails and source code. This is a massive wake-up call for developers because it shows that the old ‘castle-and-moat’ security model is simply not enough anymore.
In today’s world of remote work and multi-cloud setups, there is no single boundary to protect, and once a hacker gets inside, they can move around way too easily. Zero Trust (ZT) is a major philosophy shift that moves our defences away from static network walls to focus directly on protecting our users, assets, and actual data resources. It is not just a single product you can buy off the shelf or a simple MFA setup; it is a mindset and a set of guiding principles for how we design and operate our systems every single day.
At the heart of this approach is the ‘Assume Breach’ reality. We have to work under the premise that an attacker may already be sitting inside our environment, so we stop giving implicit trust to anyone just because they are on the office Wi-Fi or using a company laptop. Instead of trusting once and forgetting about it, we continually analyse and verify every single access request. By shrinking these ‘trust zones’ and making access control very granular, we ensure that even if one account is compromised, the damage is contained and the attacker cannot easily jump to other sensitive parts of the network.
Core pillars of the ZT model
The ‘Never Trust, Always Verify’ pillar is the foundation of Zero Trust, where we completely remove the idea of an ‘internal’ safe zone. Even if a request comes from inside the office network, trust is never granted implicitly based on location. Instead, every single communication is evaluated and secured on a per-session or per-transaction basis, ensuring that authentication and authoriation happen right before the resource is accessed.
When it comes to access, the principle of ‘Least Privilege’ is strictly enforced to stop attackers from roaming freely. Instead of giving blanket permissions to a whole network segment, we provide the absolute minimum access like ‘read’ or ‘write’ needed for a specific task. This ensures that even if a subject gets into one resource, they don’t automatically get the keys to everything else in the enterprise.
‘Identity and Contextual Awareness’ take security beyond just checking a username and password. The system looks at a dynamic mix of ‘who’ is asking and ‘how’ they are asking, including the subject’s identity, the device’s security posture (like patch levels), geolocation, and even the time of the request. By analysing these behavioural and environmental attributes, the trust algorithm can decide if the risk level is acceptable for that specific moment.
Finally, ‘Microsegmentation’ is the technical way infrastructure is broken into small, protected zones. We place individual resources or small groups of apps on their own unique segments, guarded by gateway security components or ‘Policy Enforcement Points’. This is critical for protecting ‘East-West’ traffic and preventing lateral movement, as it ensures that even if one service is compromised, the attacker is stuck in that single segment and cannot reach other crown jewel applications.
The technical blueprint (NIST logical components)
In this setup (Figure 1), the Policy Engine (PE) and Policy Administrator (PA) act as the ‘Brain’ of the operation, together forming what we call the Policy Decision Point (PDP). The PE is the actual decision-maker that uses a trust algorithm to grant, deny, or even revoke access based on enterprise policies and external data feeds. Once the PE makes a call, the PA takes over to execute that decision by establishing or shutting down the communication path between the subject and the resource.
Next, we have the Policy Enforcement Point (PEP), which serves as the ‘Gatekeeper’ that sits in the line of traffic. This is the system responsible for enabling, monitoring, and eventually terminating the connections. In a real-world deployment, the PEP is often split into two parts: a device agent on the user’s laptop and a resource gateway sitting right in front of the application or database to ensure only authorised traffic gets through.
A very important technical requirement here is the separation of planes. We keep the control plane, where our PDP and PEP communicate to manage and configure the network, logically separate from the data plane, which carries the actual application and service workload. By doing this, we ensure that no application traffic can flow until the path has been explicitly established and secured via the control plane.
To make the whole system ‘smart’, we integrate telemetry and automation using various data sources. We use Continuous Diagnostics and Mitigation (CDM) systems to keep an eye on device health and patch levels, while Security Information & Event Management (SIEM) and Threat Intelligence (TI) systems aggregate all network and system activity logs for real-time feedback. This centralised telemetry allows the policy engine to make high-confidence decisions and react to threats automatically as they happen.
Zero Trust (ZT) principles mapped to NIST components
Never trust, always verify
This ZT principle eliminates the idea of a trusted internal network. Every request, whether it is from inside or outside, is authenticated, authorised, and validated based on conditions at the time of access. Continuous verification ensures that trust is not permanent and evaluated for each session or transaction, reducing risks from compromised credentials or insider threats. For example, Microsoft Azure re-evaluates access at every login and during high-risk session changes and Google Cloud verifies identity on every application request (no persistent trust session). The PE evaluates every request, the IdP authenticates identity, and the PEP enforces decisions for each session/request.
Least privilege access
Least privilege ensures that users, applications, and devices operate with restricted permissions, reducing potential damage even if compromised. Instead of broader access rights, granular policies ensure tight control, preventing unauthorised access and lateral movement within systems. The PE determines minimal access policies, while the PA provisions short-lived, restricted access tokens. For example, Amazon Web Services grants access per request using temporary credentials (minutes to hours) and Microsoft Azure provides admin rights only for limited time windows (just-in-time activation).
Identity and contextual awareness
Security decisions are taken beyond simple authentication by evaluating multiple contextual information. Systems assess and evaluate user identity, device health, geolocation, and behavioural patterns to determine risk levels dynamically, making sure access is granted only under safe conditions. The PE determines minimal access policies, while the PA provisions short-lived, restricted access tokens. The PE uses inputs from IdP (identity), CDM (device posture), and TI (risk signals) to make context-based decisions.
Microsegmentation
Microsegmentation limits lateral movement by isolating workloads and services into smaller segments protected by policy enforcement points. Obviously, even if one segment is compromised, attackers cannot easily access other parts of the network, protecting critical assets. PEPs enforce partitioning boundaries, while the PA configures and updates segmentation policies dynamically. As an example, Microsoft Azure generally enforces rules on every packet/flow between segments and AWS validates traffic for each connection attempt between resources.
Continuous monitoring and analytics
Zero Trust relies on constant visibility into user and scheme activities. Logs, telemetry, and analytics help identify anomalies and suspicious behaviour, enabling organisations to respond quickly to potential threats and breaches. SIEM aggregates log, CDM provides system health data, and TI enriches analytics for real-time detection. Microsoft Azure analyses logs in near real-time with continuous ingestion and AWS evaluates events continuously as activity streams are generated.
Device trust and endpoint security
Devices are evaluated for confirmation before granting accession, ensuring they meet security standards such as updated patches and antivirus protection. This reduces risks from compromised or unmanaged endpoints accessing sensitive resources. CDM evaluates device posture, and the PE uses this data to allow or deny access. Interestingly, Microsoft Azure checks device compliance at login and periodically during sessions and Google Cloud verifies device attitude each time access is requested.
Strong authentication (MFA and passwordless)
Strong authentication mechanisms like MFA (multi-factor authentication) and passwordless methods add layers of security. These approaches significantly reduce the risk of credential theft and phishing attacks by requiring additional verification factors. The IdP enforces authentication mechanisms (MFA/passwordless), and the PE validates them during decision-making. Microsoft Azure enforces MFA at every login or when risk level increases mid-session and AWS requires MFA for each privileged or sensitive operation.
Assume breach mentality
This principle shifts the mindset from prevention alone to resilience. By assuming compromise, systems are designed to detect intrusions quickly and contain damage, ensuring attackers cannot move freely or escalate privileges. Microsoft Azure scans resources continuously for vulnerabilities and threats, and Google Cloud performs threat analysis in near real-time across logs and telemetry.
Automation and orchestration
Automation enables rapid response to security incidents, minimising human error and improving efficiency. Orchestrated workflows can detect, analyse, and mitigate threats automatically, ensuring faster containment. SIEM detects anomalies, TI provides threat context, and the PE adapts access decisions accordingly. Microsoft Azure triggers responses instantly when alerts are generated and Amazon Web Services executes remediation in real time upon event detection.
Data-centric security
Zero Trust shifts its focus from network security to data protection. Sensitive data is encrypted, classified, and monitored to ensure it remains secure even if infrastructure is compromised. The SIEM triggers alerts, the PE decides response actions, and the PA executes automated enforcement. Data policies define protection rules, while the PE ensures enforcement during access requests. Amazon Web Services encrypts/decrypts data on every access request and Microsoft Azure evaluates data access policies each time data is accessed or shared.
Secure Access Service Edge (SASE)
SASE integrates networking and security into a unified cloud-based model. It enables secure access to applications from anywhere, making it ideal for remote and hybrid work environments. PEPs (edge nodes) enforce access, PE evaluates policies, and IdP verifies identity for distributed users. For example, Microsoft Azure inspects traffic continuously as it flows through edge nodes and Google Cloud enforces policies for every connection request from remote users.
Policy enforcement and dynamic access control
Access control is enforced through centralised policy engines that evaluate real-time signals. These dynamic policies ensure consistent and adaptive enforcement across all systems, improving security posture. The PE evaluates policies, the PA configures enforcement, and the PEP applies controls dynamically. Amazon Web Services evaluates policies on every API call or access request and Microsoft Azure re-applies policies whenever session risk or context changes.
Zero Trust across the modern stack
In the modern world, we can’t expect everyone to be in the office, and the same goes for our apps. Many organisations now use a multi-cloud or cloud-to-cloud setup where data and services are spread across different providers. Instead of forcing every request to tunnel all the way back to the main headquarters, which just slows everything down, Zero Trust allows an application in one cloud to connect directly and securely to a data source in another. We achieve this by placing Policy Enforcement Points (PEPs) at the actual access points of each service, making the security as mobile as the data itself.
For SaaS and remote access, we have to protect ‘subjects’ (users or non-human entities) and assets that live outside our own office walls. Since these cloud-based resources are not inside a physical perimeter, we use identity-driven policies to manage access, making sure we know exactly who is requesting what, even if they are using a public network. We also assume that these local networks, like a home Wi-Fi or public hotspot, are hostile, so we insist on authenticating every connection and encrypting all traffic by default.
To make this manageable for developers, we move towards Policy as Code (PaC) and integrate security right into our CI/CD pipelines. This means we set up automated guardrails to check for things like correct identity attributes and proper encryption before anything even goes live. By treating security as a core part of the system design rather than an afterthought, we ensure that every new piece of code follows the ‘Never trust, always verify’ rule from day one.
Roadmap for developers: Step-by-step rollout
Stage 1: Discover and protect
The first step is to reach a baseline of competence by identifying and cataloguing all enterprise subjects, assets, and business processes. You must create a detailed inventory of physical and virtual devices, data classes, and the ‘actors’ (both human and service accounts) active on your network. Once you have mapped your critical business applications and their dependencies, the priority is to enable strong authentication, specifically phishing-resistant multi-factor authentication (MFA), to protect access to these resources.
Stage 2: Contain and control
After gaining visibility, you move into the ‘contain and control’ phase by formulating dynamic, risk-based access policies. This involves implementing ‘conditional access’, where the system evaluates the subject’s identity and the device’s security posture before granting a session. You should also introduce just-in-time (JIT) administration and expiring privileges to ensure that access is granted with the least privilege needed for a specific task and only for a limited duration. During this stage, it is wise to start a pilot microsegmentation project for a few ‘crown jewel’ or high-value assets (HVAs) to prove the concept without disrupting the whole organisation.
Stage 3: Microsegment and automate
In the final stage, you enforce full segmentation for all critical apps and services, ensuring they are not even discoverable without going through a Policy Enforcement Point (PEP). At this point, your Policy Engine (PE) should be in a steady operational phase, using centralised telemetry from SIEM and SOAR systems to automate risk responses. By implementing ‘Policy as Code’ and automated guardrails, you ensure that security is enforced consistently across the entire enterprise, allowing your team to focus on monitoring and refining policies based on real-time feedback.
Success metrics and pitfalls
Success metrics (KPIs):
Track your Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) using machine learning and ZTA logs to see if the architecture is helping you catch and stop threats faster.
Measure the percentage of your resources and subjects, especially those with sensitive access that are protected by multi-factor authentication (MFA).
Monitor the decrease in permanent, ‘blanket’ admin accounts in favour of dynamic, per-session access governed by a Policy Engine.
Use network and system activity logs to identify how many unauthorised attempts to move between network segments were successfully stopped by your Policy Enforcement Points (PEPs).
Pitfalls:
- Never treat Zero Trust as just a product or a single architecture; it is a long-term operating model and a set of guiding principles for workflow, system design, and operations.
- Do not try to microsegment every single resource at once; without a proper ‘tuning phase’ where policies are enforced while still allowing business processes to function, you will likely cause process failures.
- Ensure that Non-Person Entities (NPEs), such as service accounts and automated software agents, also have strict authentication and policy enforcement, as they can be coerced or impersonated by attackers.
- Avoid relying on weak telemetry or ‘shadow IT’ that isn’t monitored, because if you cannot observe the current state of assets and network traffic, your Policy Engine cannot make accurate access decisions.
Transitioning to a Zero Trust Architecture is a continuous journey of risk evaluation rather than a simple technology refresh or a wholesale replacement of existing infrastructure. Most organisations will naturally operate in a hybrid mode for an indefinite period, where modern Zero Trust workflows coexist alongside legacy perimeter-based systems. To be successful, you should seek to incrementally implement these principles, starting with your highest-value data assets while ensuring you have a deep, documented understanding of all enterprise subjects, physical and virtual assets, and critical business processes. Ultimately, by moving away from implicit trust and towards a model of continuous monitoring and granular, per-session authorisation, you can significantly reinforce your security posture and limit the potential for lateral movement within your environment.
