Zero Trust Gaps Exposed How to Close Identity and Access Risks in Enterprise Cybersecurity
Attackers do not need to “break in” when they can sign in. That is the uncomfortable truth behind many modern intrusions. Stolen credentials, session tokens, misconfigured identity providers, over-permissioned cloud roles, and weak device checks continue to give adversaries a clean path through environments that claim to be zero trust.
Verizon’s 2024 Data Breach Investigations Report again put credentials and human-driven access paths near the centre of breach activity. Microsoft has also reported password attack activity at massive scale across cloud identity systems. Recent ransomware and extortion crews, including groups associated with Scattered Spider-style tradecraft, have shown how effective this can be. They target help desks, reset MFA, abuse single sign-on, move into SaaS and cloud consoles, and then steal data before encryption is even considered.
Zero trust is not failing as a concept. The gap is execution. Many organisations bought identity tools, enabled MFA, and wrote policy statements, but left trust relationships, legacy protocols, service accounts, SaaS permissions, and privileged access workflows loosely controlled. That creates a false sense of maturity.
The threat pattern has shifted to identity control
Enterprise cybersecurity used to focus heavily on the network edge. Firewalls, VPN gateways, and endpoint controls still matter, but the centre of gravity has moved to identity. In hybrid environments, a single identity can cross on-premises systems, Microsoft Entra ID, AWS IAM, Google Cloud, Salesforce, ServiceNow, GitHub, and dozens of other SaaS platforms.
That identity becomes a master key.
Attackers commonly follow a sequence like this:
Obtain credentials through phishing, infostealer logs, credential stuffing, or help desk social engineering.
Bypass or fatigue MFA through push bombing, adversary-in-the-middle phishing, or SIM swap support abuse.
Establish persistence with new MFA methods, OAuth app consent, API tokens, or conditional access exclusions.
Escalate privileges through over-permissioned roles, dormant admin accounts, or cloud IAM misconfiguration.
Move laterally into email, file stores, identity systems, cloud storage, and administrative consoles.
Exfiltrate data, disable controls, deploy ransomware, or extort the organisation.
MITRE ATT&CK maps these behaviours clearly. Relevant techniques include Valid Accounts `T1078`, Phishing `T1566`, Multi-Factor Authentication Request Generation `T1621`, Account Manipulation `T1098`, Cloud Account abuse under valid accounts, Create or Modify System Process `T1543` in some persistence paths, and Exfiltration Over Web Service `T1567`.
The lesson is simple. If identity is weak, zero trust becomes a slogan rather than a control model.
How zero trust gaps actually work
Zero trust asks every access request to prove itself. The user, device, application, location, session risk, and requested resource should all be checked continuously. Think of it like airport security combined with hotel keycard access. A passport gets you to the checkpoint, but it should not give you access to the cockpit, baggage systems, and every hotel room for the next six months.
In practice, many environments still work like a building with excellent front-door security and unlocked internal rooms.
Gap one is trusting MFA too much
MFA is essential, but not all MFA is equal. SMS codes, push notifications without number matching, and poorly protected recovery flows can be abused. Attackers now target the weak points around MFA, not only the login form.
Common weaknesses include:
MFA exclusions for executives, break-glass accounts, service accounts, or legacy applications
No phishing-resistant authentication for administrators
Help desk reset procedures based on weak identity proofing
Long-lived sessions that survive password resets
No alerting when a new authenticator is enrolled
A user with MFA can still be compromised if the attacker steals a session token. In that case, the attacker skips the login checkpoint and presents an already stamped boarding pass.
Gap two is excessive privilege
Privilege creep is one of the quietest zero trust failures. Users move roles, projects end, emergency access is granted, and temporary permissions become permanent. Cloud environments make this worse because permissions are highly granular and often hard to interpret.
An IAM policy may look harmless, but one permission might allow a user to attach a new policy, assume a more privileged role, or read secrets. That is like giving someone a key to the cleaner’s cupboard, then discovering the cupboard contains the master key safe.
Gap three is poor device and session context
Zero trust requires more than “correct username, correct password, correct MFA”. It should ask whether the device is healthy, managed, encrypted, patched, and behaving normally.
A login from a compliant laptop in Sydney during business hours is different from a login using a new device, from an unusual network, followed by mass file downloads. If access policy treats both events the same, security operations teams inherit the risk.
Gap four is unmanaged machine identity
Service principals, API keys, certificates, workload identities, CI/CD tokens, and automation accounts often receive less scrutiny than human users. Attackers know this. Machine identities can provide quiet, durable access to cloud resources and data pipelines.
These accounts often lack clear ownership, expiry, rotation, or behavioural monitoring. In zero trust terms, they become trusted ghosts.
Quick Wins - Turn on number matching for push MFA where supported. - Block legacy authentication protocols that bypass modern controls. - Require phishing-resistant MFA for privileged roles. - Alert on new MFA method registration and conditional access policy changes. - Review all accounts excluded from MFA or conditional access. - Remove standing admin rights and use just-in-time elevation. - Rotate stale API keys and service account secrets. - Investigate impossible travel, unfamiliar sign-in properties, and mass download activity.
Build defence in depth around identity
A strong zero trust programme uses layers. No single product closes identity risk. The operating model matters as much as the toolset.
Strengthen identity provider controls
Start with the identity provider because it is the control plane for SaaS and cloud access.
For Microsoft Entra ID, Okta, Ping, or similar platforms, prioritise:
Conditional access based on user risk, sign-in risk, device compliance, location, and application sensitivity
Phishing-resistant MFA for administrators, such as FIDO2 security keys or certificate-based authentication
Privileged Identity Management or equivalent just-in-time access
Separate admin accounts with no email or web browsing
Break-glass accounts stored securely, monitored heavily, and tested regularly
Blocking of legacy authentication, including basic authentication where still present
Restricted user consent for OAuth applications
For cloud platforms, use AWS IAM Access Analyzer, Azure role assignment reviews, Google IAM Recommender, and cloud security posture management tools to detect excess access. This is where Cloud Security Posture Management connects directly to threat defense. Misconfigured identity is often the path to misused storage, exposed secrets, and unauthorised compute.
Put privileged access under strict control
Privileged access needs stronger rules than general access. Use a tiering model:
Tier | Examples | Required controls |
Critical identity administration | Global admins, domain admins, root cloud accounts | Phishing-resistant MFA, just-in-time access, session recording, separate admin workstation |
Platform administration | Cloud admins, security admins, network admins | Conditional access, privileged access workflow, approval, time-bound roles |
Business application administration | SaaS admins, finance system admins, HR platform admins | Role reviews, strong MFA, audit logging, least privilege |
Standard access | General users | Risk-based MFA, device compliance, app-level controls |
Privileged sessions should be logged into a SIEM such as Microsoft Sentinel, Splunk, Elastic, or Chronicle. High-risk events should trigger SOAR playbooks for containment.
Monitor identity signals like endpoint signals
Identity telemetry deserves the same attention as EDR alerts. Feed these sources into security operations:
Identity provider sign-in logs
Audit logs for role changes and policy changes
MFA registration and reset events
SaaS admin activity
CloudTrail, Azure Activity Logs, and Google Cloud Audit Logs
EDR device risk signals
Data security alerts from DLP, CASB, or SaaS security posture tools
Look for combinations, not only single events. A new MFA method followed by a login from a new country, followed by mailbox rule creation and SharePoint downloads, should be treated as a high-fidelity incident.
Relevant ATT&CK techniques include Email Collection `T1114`, Data from Cloud Storage `T1530`, Account Discovery `T1087`, and Permission Groups Discovery `T1069`.
Follow a practical implementation sequence
Zero trust fails when teams try to boil the ocean. A practical sequence reduces risk while keeping the business moving.
Step 1 inventory identities and access paths
Create a current inventory of:
Human users
Privileged roles
Service accounts
Cloud roles
API keys and tokens
SaaS administrators
External users and guests
Conditional access exclusions
Map each identity to an owner, system, privilege level, and last-used date. Disable or remove dormant identities after an agreed business review.
Step 2 classify applications by access risk
Not every application needs the same control level. Classify systems into tiers based on data sensitivity, operational impact, regulatory exposure, and administrative capability.
High-risk systems include identity platforms, cloud consoles, security tools, finance systems, HR systems, source code repositories, backup platforms, and production infrastructure.
Apply stronger conditional access and monitoring to these first.
Step 3 enforce phishing-resistant MFA for privileged access
Start with administrators and high-risk users. Use FIDO2 security keys, platform passkeys where suitable, or certificate-based authentication.
Configuration best practices include:
Disable SMS and voice MFA for privileged roles.
Require number matching for push MFA.
Require re-authentication for high-risk actions.
Prevent self-service MFA reset for privileged accounts without stronger verification.
Alert on any change to authentication methods for admin users.
Step 4 remove standing privilege
Use just-in-time access with approval, expiry, and logging. In Microsoft environments, use Privileged Identity Management. In AWS, use short-lived role assumption through identity federation. In Google Cloud, use time-bound IAM where available and review service account impersonation.
For emergency access, keep break-glass accounts few, protected, and monitored. They should not be convenient daily admin accounts.
Step 5 tighten device and session controls
Require managed, compliant devices for sensitive applications. Use EDR health, disk encryption, OS version, and jailbreak or root status as access signals.
For unmanaged devices, restrict access to browser-only sessions, block downloads, apply watermarking where suitable, or deny access to high-risk systems.
Session controls should include:
Shorter session lifetime for privileged portals
Continuous access evaluation where supported
Token revocation after password reset or account compromise
Re-authentication for risky changes
Alerts on impossible travel and unfamiliar sign-in properties
Step 6 protect machine identities
For service accounts and automation identities:
Assign an owner and business purpose.
Use managed identities where possible instead of static secrets.
Rotate secrets and certificates on a schedule.
Remove unused keys.
Limit permissions to exact required actions.
Monitor unusual API activity.
Store secrets in a vault such as Azure Key Vault, AWS Secrets Manager, Google Secret Manager, or HashiCorp Vault.
Machine identities should never be exempt from governance simply because no person logs in with them.
Step 7 test detection and response
Run tabletop exercises and purple team tests against identity scenarios. Test paths such as MFA reset abuse, OAuth consent abuse, privilege escalation in cloud IAM, and session token theft.
Validate that security operations can answer:
Which account was used?
Which device and IP were involved?
What changed in identity policy?
What data was accessed?
Were tokens revoked?
Were downstream SaaS sessions terminated?
Was the user’s device isolated if needed?
This turns zero trust from policy into muscle memory.
Use metrics that prove risk is shrinking
Executives do not need a 40-page control report. They need evidence that identity risk is reducing and that resilience is improving.
KPI | What it shows | Target direction |
Percentage of privileged users on phishing-resistant MFA | Strength of admin authentication | Increase |
Number of conditional access exclusions | Policy bypass risk | Decrease |
Standing privileged accounts | Persistent blast radius | Decrease |
Dormant accounts with access | Unused attack paths | Decrease |
Mean time to revoke compromised sessions | Containment speed | Decrease |
New MFA registrations investigated | Account takeover detection coverage | Increase initially, then stabilise |
Service accounts without owners | Machine identity governance gap | Decrease |
High-risk sign-ins remediated within SLA | Security operations effectiveness | Increase |
Cloud roles with excessive permissions | Cloud blast radius | Decrease |
Percentage of critical apps using SSO and conditional access | Policy coverage | Increase |
Pair these with incident metrics. Track how many identity alerts become confirmed incidents, how long investigations take, and whether playbooks reduce manual effort. Good metrics improve decisions rather than decorate dashboards.
Make zero trust a resilience programme
Zero trust is not a product rollout. It is a discipline that limits blast radius when credentials fail, devices are compromised, or cloud permissions drift. The goal is not perfect prevention. The goal is controlled failure.
A mature identity and access programme helps the business keep operating during an attack. Ransomware crews lose speed when admin rights are time-bound. Data theft becomes harder when sessions are risk-scored and downloads are controlled. Cloud compromise has less impact when roles are scoped tightly and secrets rotate. Security operations teams respond faster when identity telemetry is integrated and rehearsed.
For IT leaders, this is where the value becomes clear. Better identity control reduces outage risk, breach impact, regulatory exposure, and recovery cost. For practitioners, it gives a concrete build path: harden authentication, remove standing privilege, govern machine identities, monitor behavioural signals, and measure what changes.
Even when someone searches for Cybesecurity by mistake, the underlying priority is precise: make identity the strongest control plane in enterprise cybersecurity, not the softest entry point.
Resilience starts when every access request must earn trust, every privilege has an owner and expiry, and every identity signal feeds security operations with enough context to act.
Connect with Steve Sharma
• LinkedIn: https://www.linkedin.com/in/stevesharma-cybersecuritylink/
• Qwoted Expert Profile: https://app.qwoted.com/sources/steve-sharma
• Amazon Author Page: https://amazon.com/author/stevesharma
• Website: https://www.cybersecuritylink.com.au/about
Published Books:
The CISO's AI Firewall: A CISO's Guide to Securing, Governing, and Deploying Artificial Intelligence
• Amazon: https://www.amazon.com/dp/B0H7P45789
• Books2Read: https://books2read.com/u/bwMwDv
• Pothi: https://store.pothi.com/book/steve-sharma-the-cisos-ai-firewall
• Free Executive Mini Book: https://www.cybersecuritylink.com.au/_files/ugd/055a3f_60c8aa47e25344a89439630782eeccb2.pdf
Comments