Zero Trust in practice: where most organisations should start

Zero Trust is often described in big architecture terms, but most organisations need a practical starting point. The goal is not to buy a product. The goal is to reduce implicit trust and make access decisions based on identity, context, risk, and least privilege.

We have run Zero Trust readiness assessments across financial services, healthcare, and mid-market organisations. The patterns are consistent: every organisation has the same starting backlog, in roughly the same order. This post lays out what that backlog looks like and how to sequence the work so it produces visible improvement within 90 days, not a multi-year programme that never ships.

What Zero Trust actually means

Zero Trust is a design principle, not a product. The principle: do not assume any user, device, network, or application is trustworthy because of where it sits. Verify identity, validate device posture, evaluate context (location, time, behaviour), and grant the minimum access needed for the specific task. Re-evaluate continuously.

Most enterprise environments still rely on implicit trust in three ways. The corporate network is treated as inherently trustworthy. Users are treated as trustworthy once authenticated. Privileged accounts are granted standing privilege rather than just-in-time access. Each of these creates exposure that ransomware, credential theft, and insider risk exploit.

Zero Trust replaces those implicit trusts with explicit checks. The technical controls are mostly things that already exist in major identity and security platforms — Conditional Access, MFA, RBAC, device compliance, privileged access management, segmentation. The work is configuration, governance, and operating discipline.

Start with identity

Inventory users, administrators, service accounts, guest users, stale accounts, shared mailboxes, and privileged roles. Identity is the control plane for cloud, SaaS, collaboration, and modern infrastructure.

The questions to answer before changing anything:

• How many active human users are there, and how many are inactive?
• How many admin accounts exist, and how many of them are used regularly?
• How many service accounts authenticate against the directory, and who owns each one?
• How many guest or external accounts are present, and when were they last used?
• How many shared mailboxes can be signed into, and who has access?
• Which legacy authentication protocols (NTLM, basic auth) are still in use, and by what?

The exercise itself usually surfaces problems that did not need to wait for a Zero Trust programme — abandoned admin accounts, service accounts with passwords that have not rotated in years, ex-employees still active, guest accounts created for a contractor who left in 2022. Cleaning these up reduces attack surface immediately, before any policy change.

Enforce strong authentication

MFA should be treated as baseline protection. Prioritise administrators, remote access, email, finance systems, collaboration platforms, VPNs, and cloud consoles.

The practical sequence we recommend:

1. Administrators first. Every account with admin rights to anything — directory, cloud console, SaaS application, security tool — gets MFA enforced. No exceptions, no permanent bypass.
2. High-risk roles next. Finance, HR, IT support, anyone with access to bulk personal data, and anyone with access to financial systems.
3. All cloud and SaaS access. Microsoft 365, Google Workspace, Salesforce, the HR system, the CRM, any SaaS that touches customer data.
4. Remote access. VPN, RDP gateways, jump hosts, anything that bridges into internal systems.
5. Email second factor. Even if other systems lag, email account compromise is the single most common attack pathway.

Avoid SMS as a second factor where the platform supports something stronger. Authenticator apps (Microsoft Authenticator, Google Authenticator, Duo) are the practical default. FIDO2 hardware keys for the highest-risk accounts (domain admins, finance leaders, executives) where the operational maturity supports them.

Conditional Access (or its equivalent on AWS and Google Cloud) is where MFA becomes intelligent. Require MFA for risky sign-ins, unfamiliar locations, or unmanaged devices, while allowing seamless sign-in from compliant managed devices on trusted networks. The user experience improves at the same time as the security posture.

Reduce standing privilege

Review privileged access and remove permanent admin rights where they are not required. Separate normal user accounts from admin accounts and introduce approval, logging, or time-bound access where possible.

The pattern: nobody should be a permanent administrator of anything. Privileged access is granted just-in-time, for a specific purpose, with logging, and expires automatically. The implementation depends on the platform — Privileged Identity Management in Microsoft Entra, Privileged Access Management in IAM systems, or the equivalent capability in your tooling — but the principle is platform-agnostic.

Three changes that produce the most reduction in risk:

• Separate admin accounts from user accounts. The same person can have both, but they sign in with different identities for different purposes. Email and Slack use the standard account. Cloud console and directory admin use the privileged account.
• Time-bound elevation. The user requests elevation, the system either auto-approves based on policy or routes to a peer for approval, the elevated session expires after the documented window.
• Audit every elevation. Who elevated, when, for what purpose, what they did during the session.

Standing admin access is the single biggest exposure for ransomware. An attacker who compromises a permanent administrator account has hours or days to move laterally before the credential expires. An attacker who compromises an account that has just-in-time elevation has minutes.

Control SaaS sprawl

Many organisations have more SaaS tools than they realise. Identify which applications are connected to identity, which users have access, who owns the data, and whether access is reviewed.

The discovery questions:

• Which SaaS applications are integrated with the corporate identity provider for SSO?
• Which SaaS applications are not integrated and rely on local username/password?
• Who owns each application — finance, marketing, HR, engineering?
• Who has access to each application, and when was access last reviewed?
• What categories of data are stored in each application?
• Which applications have compliance implications (POPIA, GDPR, financial reporting)?

The rule we suggest: every SaaS application that touches customer or staff data must be in the SSO catalogue, with documented data classification, named owner, and a quarterly access review. Applications that do not meet the bar are either onboarded properly or replaced.

This is also where shadow IT often surfaces. Marketing has bought a tool, signed up with a corporate credit card, and shared logins via a shared mailbox. The Zero Trust assessment is the moment to surface the workaround and either bring the tool into governance or migrate to an approved alternative.

Improve visibility

Access logs, endpoint telemetry, cloud audit logs, email security events, and critical infrastructure alerts should be collected and reviewed. You cannot improve what you cannot see.

The minimum logging coverage:

• Identity sign-in events, MFA events, Conditional Access decisions.
• Privileged access elevation events.
• File access events on sensitive document libraries.
• Email forwarding rule changes (a common attacker persistence technique).
• Cloud audit logs across the production tenant.
• Endpoint detection events from EDR tooling on every managed device.

Logs without monitoring are evidence after an incident, not protection. The next maturity step is alerting — automated detection rules for unusual patterns. Bulk downloads, mailbox forwarding to external addresses, sign-ins from unfamiliar geographies, mass permission changes. Microsoft Sentinel, Splunk, Elastic, Wazuh, or any SIEM tool can do this. The configuration matters more than the choice.

For organisations without a 24/7 security operations centre, managed detection and response services close the gap. The trade-off is cost vs. capability — but having unmonitored logs is the worst outcome of all.

Make it operational

Zero Trust should become part of onboarding, offboarding, change control, platform design, incident response, and architecture review. It is an operating discipline, not a one-time project.

The cadence we recommend:

• Joiner/mover/leaver automation — every directory change triggers the corresponding access change in critical systems.
• Quarterly access reviews for privileged roles, sensitive SaaS applications, and shared mailboxes.
• Annual MFA registration audit — confirm every active user has registered at least one strong factor.
• Annual Conditional Access policy review — policies drift, exceptions accumulate, document and prune.
• Annual privileged access model review — who has what, why, and when was it last needed.

These are not glamorous. They are the operating discipline that converts a one-time Zero Trust project into a sustained security posture.

A 90-day starting plan

For an organisation with no Zero Trust programme in flight, the first 90 days produce more visible improvement than the next 12 months combined. The plan we run:

After 90 days, the next priorities depend on what the assessment surfaced. Common Phase 2 work: device compliance enforcement, SaaS access reviews, broader privileged access conversion, third-party risk management, and DLP rule design.

Where to start

If your organisation has not yet done a Zero Trust readiness assessment, the order we suggest mirrors the post: identity inventory, MFA, privileged access, SaaS, visibility, operations. Each step produces measurable improvement and reduces the cost of the next step.

This sits within our identity, access and SaaS security service and overlaps with our cybersecurity and compliance work. Start the conversation if you want a structured assessment of where you are against this list.