South Africa holds a record no CISO wants on their annual report: 79% of local organisations cannot clearly account for who has access to which systems. That figure puts us at the bottom of global benchmarks on identity visibility. Calling it an IT governance problem understates what it actually represents. Every unaccounted privilege is an exploitable path, and skilled attackers find those paths before your team does.
Zero Trust was built to close them. But adopting Zero Trust architecture and proving that it works are two entirely different activities, and the gap between them is precisely where most South African organisations are exposed.
Zero Trust is an architectural principle, not a product category. The core premise: no user, device, or network segment receives implicit trust, regardless of where the access request originates. Every access decision requires verification, and that verification must occur continuously, not only at initial login.
For most South African enterprises, moving toward Zero Trust means confronting access models built on decades of implicit trust assumptions. Domain-joined machines inherit broad permissions by default. VPN users land inside the network with near-flat access once authenticated. Service accounts accumulate privileges over years of quiet neglect, often running under domain admin-level permissions long after the original project that required them has ended.
The Zero Trust model demands that each of these gets evaluated on a per-session, per-resource basis, with access granted only when identity, device posture, and context all pass inspection. That is the policy. The harder question is whether the policy actually holds under active attack conditions, and the only way to answer that question credibly is through structured penetration testing that specifically targets identity infrastructure.
The attack chains that result in breaches at South African organisations rarely begin with a dramatic perimeter compromise. They begin with a valid credential. A phishing email lands in a finance team inbox, a credential stuffing attack finds a reused password from a prior breach, or a contractor's VPN account hasn't been rotated in fourteen months. At that point, the attacker operates inside your environment as a legitimate user, which changes everything about how they move.
Lateral movement follows quickly. On a network without enforced microsegmentation, a standard domain user account is enough to enumerate Active Directory, map out privileged accounts, and begin identifying access paths that no-one explicitly designed but also no-one explicitly blocked. The accounts that become priority targets are the ones your access review missed: service accounts with excessive permissions, dormant accounts with no expiry date, and shared credentials that exist outside any formal identity management process.
Privilege escalation from that foothold follows recognisable patterns. Kerberoasting targets service accounts with weak or aged passwords. AS-REP roasting attacks accounts where Kerberos pre-authentication has been disabled, often a legacy configuration that survived multiple AD migrations. Pass-the-hash attacks allow an attacker to impersonate a user without cracking their password at all. Each of these exploits gaps that look clean in an access review spreadsheet but surface immediately when an experienced tester operates against live infrastructure.
Supply chain attacks add a dimension that pure identity hygiene cannot address on its own. An attacker who compromises a managed services provider, a software vendor, or a third-party contractor arrives inside your environment carrying a trusted identity. They bypass perimeter controls entirely, and the standard perimeter-first pen test produces no useful signal about this exposure. South African organisations that rely on external partners for infrastructure management face this risk acutely, particularly where third-party access is not time-limited, scoped, or monitored.
A conventional pen test validates that controls exist. It checks whether your firewall blocks expected ports, whether your web application rejects injection attempts, and whether authenticated access to sensitive resources requires proper credentials. What it does not simulate is an attacker operating inside your environment as a legitimate user, following the exact paths that identity gaps create.
This is the structural limitation of point-in-time, perimeter-focused testing. When testers begin with no access and attempt to breach the perimeter, they test the perimeter. When they test internal systems from a segmented test network, they validate that segmentation. Neither approach fully answers the question that matters most to a CISO trying to defend identity infrastructure: what can someone do once they hold a valid identity inside the environment?
Kevin Wotshela, Managing Director, Magix, addresses this directly: "We regularly see organisations that passed their most recent annual pen test and still have hundreds of accounts with excessive privileges, service accounts running as domain admins, and no detection capability for lateral movement. The test validated everything in scope. The actual breach risk was sitting outside that scope entirely, and nobody had defined scope to include it."
The distance between what gets tested and what gets exploited is where South Africa's 79% identity visibility gap becomes a concrete attack surface, not just a compliance statistic.
A Zero Trust penetration test starts from a fundamentally different premise. Rather than asking whether an attacker can get in, it asks whether your Zero Trust controls enforce the restrictions they claim to under real attack conditions. That shift changes the testing methodology significantly.
A standard access audit asks: does this account have access to this resource? Zero Trust testing asks: can an attacker holding this identity, operating from this device, on this network segment, reach this resource in a way that bypasses your conditional access, microsegmentation, and privileged access controls? The answers frequently diverge.
Specific tests that fall within a Zero Trust validation engagement include conditional access bypass testing (verifying whether MFA can be circumvented through adversary-in-the-middle techniques or session token theft), microsegmentation validation (confirming that network segments defined as isolated cannot be pivoted through using compromised credentials or misconfigured service connections), and privileged account workflow testing (confirming that PAM controls enforce time-limited access and that standing privileges do not accumulate outside approved processes). Identity federation and SSO attack paths round out the scope, testing whether trust relationships between cloud tenants, SaaS platforms, and on-premises infrastructure can be abused to escalate access.
None of these tests appear in a standard vulnerability scan. Several will not appear in a basic internal penetration testing engagement unless the scope document explicitly includes identity infrastructure. That scoping decision is where most South African organisations fall short, and it is entirely within the control of the team commissioning the assessment.
Attempting to validate all Zero Trust controls in a single engagement is unrealistic for most IT teams. A phased approach allows your organisation to prioritise the highest-risk areas first and build a repeatable validation programme over successive testing cycles.
Phase 1: Credential and Identity Baseline. Begin with a full internal penetration test focused on identity infrastructure. Cover Active Directory enumeration, Kerberos attack surface assessment (Kerberoastable accounts, accounts with pre-authentication disabled), password policy enforcement testing, and stale account identification. This phase establishes the ground truth: which identity weaknesses exist before any Zero Trust controls are applied. The vulnerability assessment and penetration testing output from Phase 1 becomes the baseline against which all subsequent phases measure progress.
Phase 2: Microsegmentation and Lateral Movement Testing. Test whether your network segmentation controls prevent lateral movement from a compromised endpoint. A tester operating as a standard domain user should be unable to reach finance systems, backup infrastructure, or domain controllers without triggering a detection event. If they can reach any of those destinations without triggering an alert, the segmentation is either absent or unenforced. Segmentation testing at this phase is particularly valuable for organisations working toward PCI DSS compliance, where the scope of your cardholder data environment depends entirely on segmentation that actually holds.
Phase 3: Privileged Access and Conditional Access Validation. This phase tests whether your PAM and conditional access controls behave correctly under attack conditions. It includes attempting to access PAM-controlled accounts outside approved workflows, testing MFA bypass techniques, and confirming that session recording and alerting are functional. Organisations building toward PCI DSS compliance will find this phase maps directly to Requirement 7 (access control) and Requirement 8 (authentication management).
Phase 4: Supply Chain and Third-Party Access Testing. The final phase addresses third-party access, which represents one of the highest-risk exposure areas in the South African market given the prevalence of outsourced IT management. Test whether third-party accounts are properly scoped and time-limited, and whether those access paths can be used to pivot to sensitive systems. Organisations that have read our analysis of why third-party risk is now systemic risk will recognise that supply chain access is not a theoretical concern in the SA market.
South Africa's 79% identity visibility gap is not simply a compliance finding waiting to be closed with better reporting. Every organisation that cannot account for who has access to what is operating with an unknown number of exploitable paths inside their environment. Zero Trust architecture provides the framework to close those paths. Architecture without validation, though, is policy on paper.
A structured Zero Trust penetration testing programme, built across phased engagements that cover identity infrastructure, microsegmentation, privileged access controls, and third-party exposure, converts that policy into a tested and verified security posture. It gives your CISO a defensible answer when the question of whether controls actually work comes up in a board conversation, an insurance review, or a POPIA compliance assessment. It gives your operations team a concrete roadmap for closing the gaps that a perimeter-focused annual pen test never reached.
If your current testing programme is not addressing lateral movement, privilege escalation, and credential-based attack paths inside your environment, talk to the Magix team about structuring an engagement that does. The gaps are there. The question is whether you find them first.
