South Africa filed 3,219 security breach notifications with the Information Regulator in 2025/26. At an average cost of R44 million per incident, that is an estimated R141.96 billion spent on something entirely avoidable.
The average breach now costs more than four times POPIA’s maximum administrative fine. Most of these incidents trace back to the same root causes: phishing, weak credentials, ungoverned access. Permissions that should not have existed, did. That opened an attack path that never needed to exist in the first place.
Zero Trust is the architecture that keeps those paths closed. And if your organisation runs on Microsoft, you already own the tools to implement it.
What this article covers:
- What Zero Trust means
- How it maps to the Microsoft tools you are already paying for: Entra ID, Intune, Purview, Sentinel
- Why POPIA is, in effect, a legislative mandate for Zero Trust access governance
- Where most Microsoft Zero Trust implementations stall, and how to avoid those points
- A phased implementation roadmap that a mid-market South African organisation can execute
Zero Trust is a security philosophy, not a product
The phrase was coined by Forrester Research in 2010 and has since become one of the most cited terms in enterprise security.
The framework rests on three principles:
- Verify explicitly: every access request is authenticated and authorised based on all available signals: identity, device health, location, application, and data sensitivity. Nothing is trusted by default.
- Use least privilege: users and systems are granted the minimum access required to perform their function, for the minimum time required. Broad, standing permissions are replaced by scoped, time-bound ones.
- Assume breach: the network is treated as compromised by default. Controls are designed to limit the blast radius when a breach occurs, not only to prevent it.
The reason Zero Trust has become even more urgent in 2026 is that the corporate network boundary it was designed to replace no longer exists.
Employees work from home, on personal devices. Applications live in Microsoft 365, in Azure, in SaaS platforms. Data moves between Teams, SharePoint, OneDrive, and external collaborators continuously.
In that environment, access granted at the network edge provides almost no protection. In order to deepen protection, organisations need to know, at all times, whether the identity on the device is entitled to access data, and under what conditions. Zero Trust is how you answer that question systematically.
If you’re on Microsoft, you already own the toolkit
Multi-vendor security integrators have to navigate Cisco, Fortinet, Palo Alto, and Microsoft simultaneously, and their Zero Trust guidance tends to stay platform-agnostic as a result.
If your organisation is committed to the Microsoft stack (Dynamics 365, Microsoft 365, Azure), you are in a stronger position. You already own a comprehensive, integrated Zero Trust toolkit.
| Zero trust component | Questions it answers | Microsoft tool |
|---|---|---|
| Identity |
|
Microsoft Entra ID: Conditional Access, MFA, Privileged Identity Management (PIM) |
| Devices | Is this device healthy enough to be trusted with this data? | Microsoft Intune: device compliance policies, endpoint health signals |
| Data |
|
Microsoft Purview: sensitivity labels, DLP policies, data classification |
| Applications |
|
Microsoft Defender for Cloud Apps: shadow IT detection, session controls |
| Threat detection | Is something happening that should not be happening? | Microsoft Sentinel: SIEM, SOAR playbooks, threat intelligence integration |
| Network | Can this workload reach only what it needs to reach? | Azure Firewall, NSGs, Private Endpoints, micro-segmentation |
These tools share signals by design, so no stitching together is necessary:
- Entra ID evaluates identity risk
- Intune provides device compliance status
- Conditional Access combines both signals to make an access decision in real time
- Purview applies sensitivity labels that Copilot, Defender, and other tools then respect automatically
- Sentinel aggregates signals from across the environment and surfaces anomalies that individual tools would miss
This integration is what makes a Microsoft-native Zero Trust implementation different from a multi-vendor one: the architecture is coherent by design, not by a costly configuration effort that may or may not work. Forrester has corroborated this advantage, estimating up to 60% savings for organisations that migrate from the patchwork model to a unified Microsoft one.
The South African context: POPIA is a Zero Trust mandate
For any organisation processing personal information about South African residents, POPIA’s access control requirements are substantively equivalent to Zero Trust principles. The legislation is, in effect, a regulatory mandate for least-privilege access governance.
POPIA’s requirement that access to personal information be granted on a need-to-know basis is a legislative expression of least-privilege access. Every person with unnecessary access to personal data is a POPIA risk.
POPIA’s breach notification obligation requires notifying the Information Regulator and affected data subjects “as soon as reasonably possible”. This creates an operational requirement for the kind of real-time monitoring and incident detection that Microsoft Sentinel provides. You cannot notify quickly if you cannot detect quickly.
Organisations need to be able to demonstrate, on request, how personal information is protected. Microsoft Purview’s audit logs, sensitivity labels, and compliance reporting infrastructure are the mechanism by which that demonstration becomes simple and routine.
The practical implication is that a Zero Trust implementation on Microsoft is bigger than a security investment. It addresses POPIA compliance, too. Your legal and compliance function has a direct interest in this conversation, not only IT.
Where most Microsoft Zero Trust implementations stall
Zero Trust is an architecture that organisations must build progressively. This takes specific expertise and product knowledge, as well as the long-term commitment to stay the course. When mid-market organisations stall, it’s usually at one of these points.
Stall point 1: Conditional Access without data classification
Conditional Access policies are configured: MFA is enforced, compliant devices are required. But Microsoft Purview sensitivity labels have not been applied to the data those users are accessing. This creates a gap: the access decision is governed, but the data itself has no classification, so Copilot and other tools can surface sensitive information to users who should not see it even while technically respecting the Conditional Access policy.
Zero Trust at the identity layer without data classification at the Purview layer is half an architecture.
Stall point 2: Entra ID configured but Intune not enforced
Entra ID is set up and conditional access policies exist. But device compliance is not yet a condition of access. Users can authenticate from personal devices with outdated operating systems, no endpoint protection, and no BitLocker encryption, and still reach sensitive data. The “verify device” pillar of Zero Trust is absent.
This is an extremely common configuration in organisations that have deployed M365 but not yet completed their Intune rollout. It is also a gap that attackers specifically target: compromising a personal device is frequently easier than compromising a managed corporate one.
Stall point 3: Sentinel deployed but not tuned
Microsoft Sentinel is running. Alerts are firing. But nobody has built the analytics rules, Security Orchestration, Automation, and Response (SOAR) playbooks, and Security Operations Center (SOC) coverage model that makes those alerts actionable. The Security Information and Event Management (SIEM) is generating noise without generating intelligence.
A Sentinel deployment without a defined incident response process and a named owner of the alert queue is a significant investment delivering near-zero value.
A phased implementation roadmap
Getting Zero Trust right depends on a disciplined sequence. That sequence has three progressive phases, each one making the next phase possible.
| Phase | Focus | Microsoft tools | What it closes |
|---|---|---|---|
| Phase 1: Identity first (Months 1-3) | Harden identity as the primary control plane. This single phase closes the most common breach vectors: phishing, credential theft, password attacks. | Entra ID: MFA enforcement, Conditional Access baseline, Privileged Identity Management (PIM) for all admin roles. Entra ID Protection: automated risk remediation for risky sign-ins. | Many SA breaches involve human error at the identity layer. Phase 1 addresses this directly. |
| Phase 2: Data and devices (Months 3-6) | Classify data and enforce device health as a condition of access. Makes Copilot and AI tools POPIA-safe by design. | Microsoft Purview: sensitivity labels, auto-classification, DLP policies aligned to POPIA data categories. Microsoft Intune: device compliance policies, endpoint health as Conditional Access signal. | Closes the Conditional Access-without-classification gap (Stall Point 1) and the unmanaged device gap (Stall Point 2). |
| Phase 3: Detection and response (Months 6-12) | Build the operational capability to detect and respond to threats. Turns the architecture into an active defence. | Microsoft Sentinel: SIEM deployment, analytics rules, SOAR playbooks, incident response procedures. Microsoft Defender XDR: unified threat detection across M365 and Azure. SOC coverage model defined (internal or managed). | Closes the Sentinel-without-operations gap (Stall Point 3). Provides the detection capability POPIA breach notification requires. |
Identity is always the foundation. If your organisation has not yet enforced MFA for all users and applied Conditional Access baseline policies, that is where to start. It’s the highest-value step available and it does not require any additional Microsoft licensing beyond what most M365 tenants already hold.
Where are you right now? The question to answer before you start
It is very easy to overestimate an organisation’s current security posture. There’s a substantial distance between “we have M365” and “we have Zero Trust on M365.” Having Entra ID is not the same as having Conditional Access configured.
A structured readiness assessment maps your current configuration against the Zero Trust pillars, identifies the specific gaps, and produces a sequenced remediation roadmap with clear ownership. It is the difference between starting a Zero Trust programme and starting the right Zero Trust programme for your environment.
A Braintree consultant can help you move from a Microsoft 365 environment that is licensed for Zero Trust to one that is actually configured for it.
Specialists in Business Applications, Modern Workplace and Azure. Let’s grow.
