Zero Trust without buzzwords

Why the classic perimeter model is no longer enough

Employees work remotely, applications live in the cloud and external partners access data. The boundary between inside and outside effectively no longer exists. Attackers exploit exactly that: a single compromised account is often enough to move laterally unnoticed.

Historically, information security worked by gathering assets and surrounding them with a controlled perimeter. Users were considered trustworthy because they were inside it. Zero Trust inverts that assumption: trust comes from verification that happens for every request, not from location.

What Zero Trust changes

Five characteristics separate the approach from classic security models. They sound unspectacular, but they change the order in which security is planned.

• Think inside out: the value of the data and the access genuinely needed are the starting point – not the network boundary.
• Verify before trusting – for every access, not once at the morning sign-in.
• Less dependency on a physical perimeter, because protection moves to identity, device and application.
• Access decisions are risk-based rather than binary: the same user may be allowed more or less depending on the situation.
• Trust decisions are rooted in identity – of people, devices, services and workloads.

The three principles in practice

Zero Trust is not a product but an operating principle. In Microsoft environments it can be implemented step by step with existing tools.

• Verify explicitly: multi-factor authentication and Conditional Access evaluate every sign-in in context.
• Least privilege: administrative roles are activated only temporarily with Privileged Identity Management.
• Assume breach: logging, detection and segmentation limit potential damage.

Guiding principles that decide success or failure

The Cloud Security Alliance distilled a set of guiding principles from many implementations. They are deliberately technology-neutral – and in our experience they explain better than any product list why initiatives succeed or stall.

• Begin with the end in mind: business objective first, technology second. Without a clear protection goal, every measure becomes arbitrary.
• Don't overcomplicate: Zero Trust rests on long-established principles – least privilege, separation of duties, segmentation.
• Products are not the priority: tools support a strategy, they do not replace it.
• Access is a deliberate act: every permission is granted intentionally, documented and revoked again.
• Inside out, not outside in: valuable data and processes define the architecture, not the network diagram.
• Breaches happen: the goal is to keep the blast radius small and recover quickly.
• Know your risk appetite: without agreement on acceptable residual risk there are no defensible rules.
• Tone from the top: without visible leadership support, Zero Trust stays an IT topic.
• Instil a security culture: controls must be workable day to day, or they get bypassed.
• Start small and look for quick wins: visible progress funds the next steps.
• Monitor continuously: what is not observed can neither be assessed nor improved.

Nine assumptions worth letting go

Zero Trust becomes tangible once you name who you have implicitly trusted so far. The following points are not scaremongering but review questions for your own architecture.

• No trust in a network – including your own corporate network.
• No trust in transport across the internet; encryption and authentication belong in the application.
• No trust in jurisdictions: where data resides and is processed is a deliberate decision.
• No trust in third-party hardware and third-party code, including libraries and the supply chain.
• No trust in the build and deployment chain without verification and traceability.
• No blind trust in administrators – your own or your provider's. Hence dual control and time-bound rights.
• No trust in a server's location or its physical protection alone.
• No trust in an endpoint without evidence of its state: management, patch level, encryption, threat protection.
• No trust in an identity system without reviewing how accounts are created, verified and revoked.

Architecture: the building blocks of an access decision

Technically, every Zero Trust decision follows the same pattern: one component decides, another enforces. In modern architectures such as a software-defined perimeter, the connection to an application is established only after successful verification; before that the application is effectively invisible to the requester.

That is why a VPN is not Zero Trust: it connects a device to a network instead of connecting a verified user to a single application.

• Decision point: evaluates identity, device health, location, time, behaviour and risk against policy.
• Enforcement point: allows the connection, demands further verification, or blocks.
• Signal sources: identity protection, device management, threat detection, data classification.
• Segmentation: per application rather than per network, so an incident does not reach everything.
• Logging: every decision traceable, so operations and audit share one view.

From theory to Microsoft practice

In a Microsoft 365 and Azure environment most building blocks already exist. The effort rarely lies in licensing but in configuration, clean-up and operations.

• Identity: Entra ID with phishing-resistant multi-factor authentication, Conditional Access, Identity Protection.
• Privileged access: Privileged Identity Management with approval, time limits and audit trail.
• Devices: Intune compliance as a condition for access, not merely an inventory.
• Data: Purview for classification, sensitivity labels and data loss prevention.
• Detection and response: Defender XDR and Sentinel with defined alerts and ownership.
• Applications: publish access per application instead of granting network access via VPN.

Where to start?

The biggest lever is almost always identity. A clean inventory of accounts, roles and exceptions, followed by Conditional Access in report-only mode, quickly creates transparency – without disrupting operations. Device compliance with Intune and protection of sensitive data follow.

A realistic twelve-month roadmap

The following sequence has proven itself in mid-sized organisations. What matters is not speed but that each step lands in day-to-day operations before the next begins.

• Phase 1 – clarity: name the valuable data and critical processes, inventory accounts, roles and exceptions.
• Phase 2 – foundation: multi-factor authentication everywhere, define break-glass accounts, observe Conditional Access in report-only mode.
• Phase 3 – enforce: pilot policies, then enable them in stages; move administrative rights to time-bound activation.
• Phase 4 – devices: define compliance requirements and make them a condition of access.
• Phase 5 – data: introduce classification, clean up oversharing, apply DLP where it genuinely helps.
• Phase 6 – operations: rehearse detection, alerting and recovery; give exceptions an expiry date and review them regularly.

Making the case to the board

Zero Trust rarely fails on technology, often on funding. Talk only about attacks and you get a security budget; talk about business capability and you get a strategy. These arguments hold in almost any organisation.

• Lower incident follow-up costs, because the blast radius is limited.
• Higher operational stability and faster recovery after disruption.
• More agility: acquisitions, sites and partners can be onboarded faster.
• Easier evidence for customers, auditors and regulators – for example under NIS2 or ISO 27001.
• Safe adoption of new technology, including AI tools such as Microsoft 365 Copilot.
• Better use of existing investments instead of additional point solutions.
• Less friction for employees when sign-ins are risk-based rather than uniformly strict.

How to recognise progress

Without measures, Zero Trust stays a matter of opinion. These metrics can be collected with existing tooling and work for board-level reporting.

• Share of sign-ins using phishing-resistant multi-factor authentication.
• Number of permanently privileged accounts – the curve should fall.
• Share of access from managed and compliant devices.
• Number of open exceptions and their age.
• Time from suspicious signal to response.
• Share of classified documents in the areas that need protection.

Typical mistakes

Policies are often activated without a pilot phase, emergency accounts are forgotten or exceptions are never reviewed. Zero Trust succeeds when rules are documented, tested and regularly refined.

• Buying a product and calling it Zero Trust without clarifying policies and ownership.
• Tackling everything at once instead of starting with the most valuable data and the biggest risks.
• Looking only at employees and forgetting service accounts, automation and provider access.
• Creating exceptions with no expiry date and no owner.
• Collecting logs nobody reviews and treating that as security.
• Leaving employees out – unworkable rules reliably get bypassed.

Conclusion

Zero Trust is less spectacular than the term suggests: familiar security principles, applied consistently to a world without a network boundary. Getting there is not a large investment but a sequence of small, verifiable decisions – starting with identity, backed by leadership, and measurable in operations.

Sources and further reading

The strategic guiding principles and lines of argument in this article follow the vendor-neutral publications of the Cloud Security Alliance. They are freely available and a good place to start.

• Cloud Security Alliance: Zero Trust as a Security Philosophy (2023)
• Cloud Security Alliance: Zero Trust Guiding Principles (2023)
• Cloud Security Alliance: Communicating the Business Value of Zero Trust (2023)
• Cloud Security Alliance: CCZT – Certificate of Competence in Zero Trust, study material on architecture and software-defined perimeter (2025)
• NIST SP 800-207: Zero Trust Architecture