Why teams approve risky access and how to change behaviour to make secure choice the easy choice

We’ve all seen the same little horror film play out in Slack, Teams, an email at 4.58 pm, or a ticket queue:

“Can I get admin for prod?”
“Just for a day.”
“Promise.”

And because nobody wants to be that person who blocks delivery (or incident response, or month-end close), the request gets approved and we rubber stamp risk. The problem isn’t that our colleagues are reckless. As something of an amateur psychologist, I find this fascinating. The problem is that access requests are a human decision system bolted onto a technical control plane, usually with poor visibility, weak defaults, and incentives that quietly reward “yes”.

Verizon’s DBIR keeps reminding us that humans remain central to security outcomes: 68% of breaches involved a non-malicious human element (errors, falling for social engineering, etc.).  Identity risk doesn’t just arrive via evil genius attackers and nation-state bad actors in a bunker somewhere. It arrives via tired people doing “the sensible thing” in a badly designed process.

Why we Rubber-Stamp Risk

Decision Fatigue Meets Ambiguity

Approvers are typically asked to make a high-impact choice with low-context inputs:

• What exactly does this role allow?
• What’s the blast radius (projects, accounts, datasets, repos)?
• Is the requestor already over-privileged?
• Is this human, a service identity, or a stale account?
• Did they use this access last time?

When we don’t show that context, we shouldn’t be shocked when approvals drift toward “approve and move on”. Security fatigue and users becoming desensitized to cyberattacks are a real, measured phenomenon: when people face repeated security decisions, alas they often choose the path of least resistance. 

“A general ‘law of least effort’ applies to cognitive as well as physical exertion.”
- Daniel Kahneman, Thinking, Fast and Slow [2011]

Social Pressure and The “Blocker” Tax

Saying “no” has social consequences. Saying “yes” feels safe. In most organizations, the fastest way to make yourself unpopular is to delay someone else’s work with a request for detail. So we approve “temporarily”… and, as sure as someone will click the phish, temporary becomes standing privilege.

Default Bias: Whatever’s Easiest Wins

Security researchers have argued for decades that usability drives security behavior. “Users are not the enemy”; they’re responding rationally to friction. If access requests require a portal, a form, three approvals, and a wait, people route around it. If approvals are one click with no expiry, we get privilege creep.

The Fix: Change The Choice Architecture

If we want different outcomes, we design a system where:

1. Low-risk requests are fast.
2. High-risk requests are slower with better evidence.
3. Access expires by default.

That means shifting from “who approved it” to “should it be allowed, right now, for this long, at this scope”.

Practical Risk Context For Access Requests

We can make approvals better by making risk visible in plain terms. A simple bit of risk context (even if imperfect) changes behavior because it reduces ambiguity.

Example context:

• Privilege level (reader vs admin vs “can change IAM”)
• Data sensitivity (customer PII, financials, prod secrets)
• Scope (one repo vs whole org, one project vs all accounts)
• Time bound (15 minutes vs 7 days vs “forever”)
• Identity confidence (MFA, device posture, geo, recent anomalies)
• Usage evidence (last used, never used, peer baseline)

Then we treat requests like traffic lights:

• Green: Pre-approved by policy with automatic expiry
• Amber: Manager approval with clear context and a short default duration
• Red: Security or resource owner review, with justification and break-glass controls

This is how we turn access requests into a risk-managed control, not a judgement call, where approvals are based on:

• Familiarity (“Oh, it’s Dave, he’s fine.”)
• Urgency (“They need it for prod now.”)
• Habit (“We always approve this role.”)
• Trust rather than evidence

In other words, the decision is driven by social context and intuition instead of measurable risk signals.

Zero Standing Privilege Without A Productivity Revolt

Attackers still love identity. Microsoft’s Digital Defense Report notes 97% of identity attacks were password spray attacks: the boring, scalable kind. That’s exactly why standing privilege is so costly: once an identity is compromised, long-lived access becomes an express lane to impact.

So we don’t just want “better approvals”. We want zero standing privilege (ZSP) patterns:

• Just-in-time access (JIT) with enforced expiry
• Time-bound group/role membership instead of permanent grants
• Automated deprovisioning when HR status changes
• Continuous entitlement visibility so we can prove least privilege and catch drift

“Human rational behavior is shaped by a scissors whose two blades are the structure of task environments and the computational capabilities of the actor.”- Herbert A. Simon, Invariants of Human Behavior [1990]

In plainer terms: Decisions are shaped by environment + cognitive limits.

In practice, the easiest way to make this stick is to put the workflow where people already work and keep the decision payload consistent. That’s why chat-based approvals matter: approvals can happen in Slack/Microsoft Teams while still being policy-driven, time-bound, and fully audited. 

(And yes, it also stops the “I never saw the ticket” excuse. Miracles do happen.)

The Integration Story: Behavior Change At Scale

A modern identity governance approach lives or dies on integration coverage. The point isn’t “more connectors”. The point is: integration turns our policies into enforcement across the estate.

• IdPs (Entra ID / Okta): where group membership becomes the real policy engine. Time-bound group joins are the cleanest JIT pattern for many orgs.
• Cloud (AWS / Azure / GCP): where the dangerous permissions live. We need entitlement visibility, scoped access, and revocation that actually happens.
• ChatOps (Slack / Teams): where we remove friction while standardizing approvals and capturing audit evidence.
• HR (Workday / Rippling): where “is this person still here?” becomes an automated signal, not a ticket and a prayer.
• Data/Dev platforms (Snowflake / GitHub / GitLab): where “just grant admin” is the default failure mode. JIT + scoped roles stops privilege inflation. 

That integration mesh is how we make access requests safer without making the rest of the organization our enemy.

ROI: The Boring Bit That Pays For The Fun Bit

Even if we ignore worst-case events, identity-driven incidents are expensive because they’re noisy, cross-system, and slow to unwind. IBM’s Cost of a Data Breach Report 2025 puts the global average breach cost around $4.44 million.

We can sell investment using a simple framework:

• ROSI (Return on Security Investment):
  
  
  
  • Hours saved in approvals and access reviews.
  • Fewer incidents from over-privilege.
  • Reduced audit effort (evidence on demand).
    
    
• FAIR-style framing: frequency × magnitude, with “standing privilege” as a force multiplier on impact.
  
  
• Reporting cadence: monthly “access risk” scorecards + quarterly entitlement reviews.

If we show the board a trendline, like less standing privilege, faster revocation, fewer red approvals, more automated green approvals, we stop arguing about feelings and start showing numbers. And boy, the C-suite loves numbers.

Frictionless and Controlled Access Requests

The goal isn’t to “train people to approve better”. The goal is to make the safest outcome the default outcome: policy-driven, evidence-backed, time-bound access, delivered through the tools people already use, enforced automatically, and reported in business language.

When access requests become frictionless and controlled, we finally get the thing we’ve wanted all along: less risk, less noise, and fewer late-night adventures in “who approved admin for prod and why is it still there?”

‍