Zero trust doesn't secure an environment by declaration. It secures one through tested evidence: controls that have been validated, not assumed. South African enterprises increasingly commission zero trust assessments as part of a broader vulnerability assessment and penetration testing programme, and what those assessments consistently find is that the access model looks sound on paper while the actual enforcement is full of gaps.
The failures below surface repeatedly across penetration testing engagements at mid-to-large South African organisations. Each one is specific, each one enables a concrete attack path, and each one remains invisible to the standard permission review or annual access audit that most security teams rely on. If your last access verification exercise was a manual role audit, you've documented your access controls. You haven't tested them.
Service accounts are a core part of every enterprise environment. They handle scheduled tasks, system integrations, application-to-database connections, and automation workflows that require non-interactive authentication. The problem isn't that they exist. The problem is that in most environments assessed, a single service account password hasn't been rotated in twelve months or longer, the same credentials are reused across multiple systems, and the account carries administrative rights well beyond what any individual task requires.
The attack vector is lateral movement combined with credential reuse. An attacker who extracts a service account password from a config file, a memory dump, or a misconfigured application server doesn't just compromise that server. They inherit access to every system that accepts those same credentials. When the service account carries domain-level or broad network privileges, that single foothold can become full domain compromise within hours, with no brute-force alarm triggered because the credentials are entirely valid.
Traditional permission audits miss this because they verify that accounts exist and are provisioned correctly. They don't follow the credentials to their logical conclusion across every connected system. An internal penetration testing engagement does exactly that: service account enumeration through Active Directory, credential extraction simulation, and cross-system replay to validate the actual blast radius. Privilege access management controls, including credential vaulting, just-in-time provisioning, and automated rotation, close this window before attackers find it.
Every organisation has them: admin accounts belonging to former employees, contractors who finished their engagement six months ago, or project users provisioned for a deployment that completed well over a year back. Identity reviews flag them occasionally, but the gap between "flagged" and "disabled" is often measured in weeks. In organisations without a formal off-boarding process tied directly to access revocation, some accounts stay active indefinitely.
The attack vector is privilege escalation and direct system access without any brute-force attempt. A threat actor who obtains stale admin credentials, through phishing, credential stuffing, or a breach at a third-party service where the former employee reused their password, can enter your environment through a door you believe is closed.
Standard permission audits work from a list of current employees and flag obvious orphans. What they miss is the lag between an HR update and IAM action, contractor accounts provisioned outside the main HR workflow, and shared accounts that were never tied to a specific individual. A proper internal penetration test approaches this differently: enumerate all privileged accounts, cross-reference against last login date and last password change, then attempt authentication against accounts showing zero recent activity with commonly reused credential patterns. Pairing this with continuous vulnerability management and user activity monitoring creates the ongoing visibility a point-in-time audit cannot.
Cloud environments accelerate permission sprawl faster than any on-premises setup. Developers and operations teams provision IAM roles to move quickly: a role created for a specific project gets broadened when something breaks, a temporary permission that was meant to last forty-eight hours gets forgotten, and inherited policies from cloned role templates carry permissions that were never intended for the new use case.
The attack vector is cloud privilege escalation. An attacker who compromises any cloud workload with an overly permissive IAM role doesn't just own that workload. They can enumerate the cloud environment, read secrets from a secrets manager, access sensitive storage, pivot to other accounts in the same organisation, and potentially deploy resources under your billing account. When combined with public-facing cloud workloads, the entry point requires no internal foothold at all.
Standard permission reviews look at what roles are assigned. Cloud penetration testing evaluates effective permissions, which accounts for what role inheritance, policy attachments, and permission boundaries actually grant when the full chain is resolved. Testers also validate whether cloud resources expose endpoints that assume implicit internal trust, an assumption zero trust explicitly rejects. South African enterprises migrating workloads to AWS, Azure, or GCP frequently carry legacy permission models from on-premises environments into cloud configurations, and the result is a zero trust policy on the surface with a flat permission model underneath.
Third-party vendors, managed service providers, auditors, and integrators regularly require access to internal systems. The issue is that "temporary" access frequently becomes permanent. A vendor account provisioned for a deployment project two years ago may still be active, still carry valid credentials, and still have network access to systems that have since been connected to sensitive data. Unless someone specifically reviewed it, neither the vendor nor the enterprise knows the account is in a live, exploitable state.
The attack vector is third-party lateral movement and supply chain compromise. An attacker who breaches the vendor's environment, or finds the vendor's credentials in a public repository or phishing campaign, can use that account to enter your environment through the legitimate access path that was never closed. There's no anomaly to detect because the authentication looks entirely normal.
"We see inherited vendor access in almost every enterprise assessment we run," said Kevin Wotshela, Managing Director, Magix. "The vendor completed their work years ago. The account is still active, still carries permissions, and nobody on either side is monitoring it. That is a governance failure, and attackers are very good at finding exactly these kinds of gaps."
Vendor accounts sit outside normal HR workflows and are frequently absent from identity governance processes entirely. Proper third party risk management programmes address this through access lifecycle governance and formal off-boarding. A penetration testing engagement catches the actual exposure through vendor account enumeration, session token validation, and testing whether the access scope is proportionate to what the vendor's current role actually requires.
RBAC is the standard access model in most enterprise environments. Permissions are assigned to roles, users are assigned to roles, and in theory nobody holds more access than their function requires. The reality surfaced in zero trust assessments is that role hierarchies have accumulated years of modifications, exceptions, and inherited permissions that nobody fully mapped.
The attack vector is horizontal privilege escalation. A user who should only access their own data can reach records belonging to peers in the same role group. A role that was scoped for read access to one system has inherited write permissions on another through a policy applied to a parent group three years ago. The user didn't receive explicit elevated access; they inherited it through a chain that nobody traced.
A standard permission review checks what roles a user is directly assigned to. A proper access control assessment traces the effective permission set that results from every group membership, policy inheritance, and role composition in the full chain. Web application penetration testing adds coverage at the application layer, where RBAC enforcement in business logic is tested independently of what the identity provider reports. Organisations that have undergone acquisitions, mergers, or multiple system migrations are particularly exposed here, because permission structures that made sense in a legacy environment frequently get imported wholesale into new systems without a clean re-scope.
Zero trust explicitly requires that network segments are isolated and that lateral movement is constrained even for authenticated users and devices. The premise that a flat internal network can be trusted is supposed to be retired. In many assessed environments, the zero trust policy exists at the identity layer while the underlying network remains poorly segmented in practice.
The attack vector is unrestricted lateral movement after initial compromise. An attacker who gains a foothold on any host in an under-segmented zone can scan, enumerate, and connect to other hosts without encountering additional authentication or policy enforcement. They may cross into what should be isolated PCI DSS cardholder data environments, production databases, or backup infrastructure if segmentation rules haven't been tested against actual traffic paths.
The gap between documented segmentation and enforced segmentation is one of the most reliable findings in network penetration testing and segmentation testing engagements. Firewall rules, VLAN boundaries, and zero trust policy configurations are all documented somewhere. But documentation and enforcement are different things. A segmentation test validates whether a host in one zone can actually reach hosts in another, what traffic paths exist that policy documentation doesn't account for, and whether inter-segment authentication is enforced in both directions. Under PCI DSS 4.0 Requirement 11.4, segmentation testing is a mandatory compliance control for organisations in scope. For everyone else, it remains the most reliable way to validate whether micro-segmentation is real or assumed.
The expansion of internal APIs and microservices has created a credential category that most organisations haven't fully accounted for in their access control frameworks: service tokens, API keys, and OAuth credentials that authenticate applications to each other. These tokens are typically generated with broad scopes during development to simplify testing, stored in environment configuration files or source code repositories, and never re-scoped or rotated before deployment to production.
The attack vector is data exfiltration and application-level lateral movement. A token authorised for a customer data API that was originally scoped for internal analytics doesn't just expose that analytics function. It exposes every endpoint the token is authorised to call. An attacker who extracts a token from a misconfigured server, a public repository, or a container image can enumerate what the token can access and extract data at scale, often without generating the kind of network noise that detection tooling monitors for.
Traditional permission audits don't scan source code repositories for committed secrets or validate effective API token scope in production environments. API penetration testing and application security assessments do. Testers extract tokens through standard attack vectors, enumerate accessible endpoints using the token's own permissions, and validate whether scope limitations are enforced at the API gateway or simply assumed. For South African organisations processing personal information under POPIA, an exposed service token with broad data access creates both a breach risk under Section 22 and a regulatory exposure that extends well beyond the technical finding.
Access control failures don't announce themselves. They accumulate through provisioning shortcuts, vendor onboarding decisions made under time pressure, and permission modifications that were never reversed. The organisations that find these failures during a structured zero trust assessment are in a far better position than those who find them after a breach notification arrives.
If your access controls haven't been tested through a dedicated vulnerability assessment and penetration testing engagement, they haven't been tested. Magix penetration testing services cover internal access control testing, cloud IAM validation, vendor access enumeration, API credential assessment, and segmentation validation as part of a structured zero trust verification programme. If you're ready to find out what your access model actually enforces rather than what it documents, contact the team to discuss a scoped assessment.
