Zero Trust Architecture in Practice: Applying the NCSC's Eight Principles to Microsoft 365, Azure and AWS

"Zero trust" has been stretched so far by marketing that many security leaders now roll their eyes at it. That is a pity, because the underlying idea is sound and increasingly necessary. Work happens on personal devices, from home networks, in SaaS applications and across multiple clouds. The corporate network perimeter that once separated trusted from untrusted is no longer where most risk sits. Zero trust replaces the question "is this request coming from inside our network?" with "should this user, on this device, be allowed to do this, right now?"

The UK's National Cyber Security Centre has published eight zero trust architecture design principles, and the US NIST SP 800-207 provides a detailed reference model. This article maps the NCSC principles to concrete controls in Microsoft 365, Entra ID, Azure and AWS, because that is where most UK organisations will implement them.

The NCSC's eight principles, mapped to controls

1. Know your architecture, including users, devices, services and data

You cannot write access policies for assets you do not know about. Build and maintain inventories of identities, managed and unmanaged devices, cloud subscriptions and accounts, SaaS applications and where sensitive data is stored. In practice, that means Entra ID and Intune for users and devices, Defender for Cloud Apps for SaaS discovery, and the native inventories in AWS Organizations and Azure Resource Graph.

2. Know your user, service and device identities

Every user, workload and device needs a strong, unique identity. For people, that means a single identity provider with phishing-resistant MFA such as FIDO2 security keys, passkeys or Windows Hello for Business. For workloads, it means managed identities in Azure and IAM roles in AWS instead of long-lived keys. Shared accounts and static access keys are the opposite of zero trust.

3. Assess user behaviour, device and service health

Access decisions should take account of signals: is the device managed and compliant, is the sign-in risk elevated, is the location unusual? Intune compliance policies and Entra ID Protection risk signals provide this in Microsoft environments.

4. Use policies to authorise requests

Policy engines turn those signals into decisions. In Microsoft 365, Conditional Access is the policy engine: require compliant devices for sensitive applications, block legacy authentication, and require stronger authentication for administrators. In AWS, service control policies and permission boundaries set organisation-wide guardrails, while IAM policies grant specific access.

5. Authenticate and authorise everywhere

Each request should be authenticated and authorised, not just the first login of the day. Use short session lifetimes for sensitive applications, continuous access evaluation where supported, and just-in-time elevation for privileged roles through Entra Privileged Identity Management or AWS IAM Identity Center permission sets with time-bound access.

6. Focus your monitoring on users, devices and services

With the network no longer the boundary, monitoring has to follow identities and workloads. Sign-in logs, audit logs, endpoint telemetry and cloud control plane logs, such as AWS CloudTrail and Azure Activity Logs, matter more than perimeter firewall logs. Our managed detection and response buyer's guide covers how to get that monitoring in place.

7. Do not trust any network, including your own

Treat the office network as hostile. Encrypt traffic end to end, publish internal applications through identity-aware proxies such as Entra application proxy or a zero trust network access service rather than broad VPN access, and avoid rules that grant access purely because a request comes from a corporate IP range.

8. Choose services designed for zero trust

When buying new services, prefer those that support modern authentication, single sign-on, granular authorisation and good logging. Legacy applications that only support network-based trust should be isolated and placed on a modernisation plan.

Where zero trust programmes go wrong

• Buying a product first. No single product delivers zero trust. Start from principles and existing licences; many Microsoft 365 tenants already own the capabilities they need.
• Ignoring privilege creep. Permissions accumulate over time. Our article on eliminating cloud IAM privilege creep explains how to find and remove it across AWS and Azure.
• Breaking the business. Roll out Conditional Access policies in report-only mode first, and pilot with a small group before enforcing.
• Forgetting AI. AI assistants and agents inherit user permissions. Zero trust work directly reduces what tools such as Copilot can expose; see our Copilot security review.

Proving it works

Zero trust controls drift. A Conditional Access exclusion added for a quick fix, a new admin role, a storage account opened to the internet. Regular configuration checks against frameworks such as the CIS Benchmarks catch that drift. PyraLink Prove provides this evidence across AWS and Azure, mapped to ISO 27001, SOC 2 and other frameworks.

Do not forget data and workloads

Zero trust conversations often focus on users and devices, but the same principles apply to workloads and data. Service-to-service communication inside a cloud environment should be authenticated, ideally using workload identities rather than shared secrets. Storage accounts and buckets should not be reachable from the internet unless there is a specific need, and access to sensitive data stores should be granted to identities, not to network ranges. Private endpoints in Azure and VPC endpoints in AWS help keep traffic to platform services off the public internet, but they complement identity-based authorisation rather than replacing it.

Data classification closes the loop. Sensitivity labels in Microsoft Purview, or tagging in AWS and Azure, let policies treat confidential data differently from public information, for example requiring a compliant device to open a labelled document or blocking downloads on unmanaged devices. Without classification, every policy has to assume every file is equally sensitive, which leads either to over-restriction that frustrates users or to under-protection of the data that matters.

Finally, plan for break-glass access. Emergency administrator accounts excluded from normal Conditional Access policies are necessary, but they must be few in number, protected by strong credentials stored securely, and monitored so that any use raises an immediate alert.

How Pyralink helps

PyraLink™ Prove checks identity and cloud configuration across AWS and Azure with read-only access, so drift from your zero trust design shows up in the evidence rather than as a surprise. The same evidence supports certification goals such as ISO 27001 and Cyber Essentials.

Frequently asked questions

What is zero trust architecture?

Zero trust is a security approach where no user, device or network is trusted by default. Every access request is authenticated and authorised based on identity, device health and context, rather than network location.

What are the NCSC zero trust principles?

The NCSC's eight principles are: know your architecture; know your user, service and device identities; assess user behaviour, device and service health; use policies to authorise requests; authenticate and authorise everywhere; focus monitoring on users, devices and services; do not trust any network; and choose services designed for zero trust.

Can we implement zero trust with Microsoft 365?

Microsoft 365 and Entra ID provide many core capabilities, including Conditional Access, device compliance through Intune, risk-based sign-in and Privileged Identity Management, depending on licence level.

Does zero trust replace VPNs?

Often, for access to applications. Identity-aware proxies and zero trust network access services can replace broad VPN access with per-application access decisions.

How long does a zero trust programme take?

Zero trust is a journey rather than a project. Foundational controls such as MFA and blocking legacy authentication can be achieved quickly; full adoption across devices, applications and data takes longer.

Sources: NCSC: Zero trust architecture design principles; NIST SP 800-207: Zero Trust Architecture; Microsoft Learn: Conditional Access overview; AWS: Service control policies; CIS Benchmarks.