How should security teams operationalise zero trust when access requests, SaaS sprawl, and staffing shortages are all increasing at once?

Security teams should treat zero trust as an operating model, not a slogan. That means verifying every access request, using automation to remove manual approval bottlenecks, and prioritising controls that scale across SaaS and hybrid environments. The practical test is whether access decisions remain consistent, auditable, and fast enough to keep pace with business change and a thin security workforce.

Operationalising zero trust under higher request volume

Zero trust works best when it is treated as a decision system with clear policy, not a one-time architecture project. As access requests rise, teams need to make the approval path repeatable, enforceable, and observable, so the same request gets the same decision whether it comes from a new hire, a contractor, or a service account.

That shifts the centre of gravity from manual review to policy-driven enforcement. Access should be granted only when the request can be evaluated against business need, risk, and standing privilege, with automation handling routine approvals and renewals. For environments built around SaaS, that also means the control plane has to keep up with application-level entitlements, not just network boundaries.

When the operating model is working, the security team can answer three questions quickly: who asked, what they need, and how long they should have it. The practical challenge is that zero trust breaks down if every exception becomes a ticket queue, because the backlog itself becomes a shadow authorisation layer.

Why SaaS sprawl changes the zero-trust problem

SaaS sprawl increases the number of places where access can be granted, inherited, or forgotten. In practice, that means zero trust has to cover federated login, application permissions, delegated admin paths, and the long tail of integrations that often bypass central review. The security risk is not just too much access, but inconsistent access across overlapping systems.

Teams should prioritise the controls that reduce hidden privilege and make entitlement drift visible. That usually means standardising identity sources, tightening role design, and continuously reviewing who can do what inside each SaaS platform. NHIMG’s Ultimate Guide to NHIs is useful here because SaaS sprawl often expands the number of credentials, tokens, and privileged integrations that need the same discipline as user access.

A useful indicator is whether your access model can survive app turnover. If a business unit adds a new SaaS tool and the approval logic, logging, and revocation process cannot follow it without bespoke work, then the organisation has not operationalised zero trust, it has merely centralised the pain.

How to scale zero trust with a thin security workforce

Staffing shortages make prioritisation part of the control design. Security teams do not have to automate every decision, but they do need to reserve human judgment for cases that change exposure materially, such as high privilege, cross-environment access, unusual data sensitivity, or exception requests with no clear owner. Routine, low-risk approvals should be as automated as possible.

The best leverage comes from standard requests, pre-approved patterns, and measurable exception handling. If a request can be expressed as a policy rule, a joiner-mover-leaver event, or a time-bound entitlement, it should not consume senior analyst time. NIST AI Risk Management Framework is not the main control model for this topic, but its emphasis on governance, traceability, and managed outcomes aligns well with the operational discipline zero trust needs.

Security leaders should also decide where not to automate. Exception approval, segregation-of-duties conflicts, and access to critical production systems still need review that is accountable, not just fast. The goal is not maximum automation, but minimum manual effort for controls that can be expressed consistently without losing auditability or increasing blast radius.

Risk and Threat Considerations

As request volume, SaaS sprawl, and staffing pressure rise together, the main risk is control dilution. Teams start approving faster than they can verify, revoking slower than they can grant, and relying on incomplete inventories that hide stale entitlements, orphaned access, and excessive privilege.

Failure mechanism: manual queues and fragmented SaaS administration create inconsistent decisions, which makes it easier for excess access to persist, for exceptions to accumulate, and for compromise paths to remain open after role changes or offboarding.

Impact: the organisation gets a larger attack surface, weaker auditability, and slower containment when an account, integration, or delegated admin path is abused. Over time, zero trust degrades from a policy model into an aspiration that cannot keep pace with business change.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	Policy Enforcement Point — Policy Enforcement Point	Directly governs request-time enforcement and consistent access decisions.
	Least Privilege — Least Privilege	Zero trust operationalisation depends on minimising standing access across SaaS and hybrid systems.
	Continuous Verification — Continuous Verification	The question centres on verifying every access request as conditions change.
Recommendation — Place access decisions behind policy enforcement points and require evaluation before granting access. Restrict entitlements to the minimum access needed and avoid standing privilege wherever possible. Continuously re-evaluate access context instead of treating a prior approval as permanent.
CIS Controls v8	6.3 — Access Granting and Revocation	Operationalises fast, auditable access grants and revocation under staffing constraints.
	6.8 — Account Management	SaaS sprawl increases the number of accounts and entitlements that need central governance.
Recommendation — Automate access granting and revocation workflows so approvals and removals stay timely and traceable. Maintain accurate account inventories and review SaaS entitlements on a scheduled basis.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Zero trust requires governed access control, authentication, and entitlement decisions.
	GV.RM — Risk Management Strategy	Staffing shortages force explicit prioritisation of which access controls to automate first.
Recommendation — Enforce identity and access controls that validate requests and limit unnecessary access. Set a risk-based strategy for which access workflows to automate and which to keep human-reviewed.
OWASP Non-Human Identity Top 10	NHI-01 — Secret Sprawl and Credential Hygiene	SaaS and automation increase credential and token sprawl, which zero trust must control.
Recommendation — Inventory and reduce exposed secrets, then rotate or revoke them on a defined schedule.

Practitioner Guidance

What to prioritise: Start with the request types that create the most privilege and the least repeatability, then automate the routine cases around them. That gives the fastest reduction in queue pressure without blindly automating the highest-risk approvals.

What to verify: Check that every automated path still produces an auditable decision record, an expiry condition, and a revocation path. If any of those are missing, the control is only accelerating risk.

Decision rule: If a request changes standing privilege, crosses tenancy or environment boundaries, or affects production administration, treat it as an exception path and require explicit ownership. If it is a standard, time-bound entitlement, automate it and measure the exception rate.

Practitioner takeaway: Zero trust becomes operationally real when speed, consistency, and revocation are designed together; if one of those three is missing, staffing pressure will quietly recreate the very trust assumptions zero trust is meant to remove.