Security policies don't fail because they're too weak. They fail because users can't work with them. The real math on context-based access friction — and how to balance protection with productivity.
Your security team loves the new conditional access policy. MFA required for access from new locations. Blocks compromised credentials from foreign countries. Clean security win.
Your sales team hates it. Every client visit triggers MFA. Airport wifi? MFA. Hotel network? MFA. Coffee shop between meetings? MFA. Conference venue? MFA. Five MFA prompts in one day because five different networks.
Your CEO really hates it. Traveled to London for partnership discussions. MFA prompt during critical meeting. Phone battery dead. Can't complete MFA. Can't access presentation. Meeting delayed while CEO finds charger, completes MFA, reopens presentation. Partnership nearly derailed by authentication flow.
Thursday morning all-hands: CEO announces whoever implemented this policy should "think hard about whether they want to keep working here."
Friday morning: Policy disabled.
This is the context-based access control user experience problem. Policies that make perfect sense from security perspective create friction that users find unacceptable. Security team thinks "additional verification for unusual access patterns." Users experience "can't work because policy keeps blocking me."
The conflict isn't about security vs no security. It's about sustainable security vs security that gets disabled because the pain exceeds the value. And sustainable security requires understanding user experience, measuring friction, and balancing protection with productivity.
In this article:
- Why Security and Users Clash
- The Common UX Failures
- The Real Cost of Friction
- Measuring User Experience Impact
- Balancing Security and Productivity
- Testing That Includes UX
- Communication That Actually Works
- When to Roll Back
- The Balance Is Possible
Why Security and Users Clash
Security teams and end users have fundamentally different priorities:
Security Team Perspective
Primary goal: Prevent unauthorized access, protect company data, reduce risk.
Success metrics:
- Blocked attack attempts
- Reduced credential compromises
- Compliance requirements satisfied
- Security incidents prevented
Acceptable tradeoff: Some user friction in exchange for better security. "Users will adapt" to new authentication requirements.
Risk assessment: Overweight security failures (breaches, compliance violations, incidents). Underweight productivity losses (a few extra seconds for MFA seems trivial).
Not personally affected: Security team usually has exceptions, privileged access, or high tolerance for security measures. Doesn't experience full friction of policies they create.
End User Perspective
Primary goal: Get work done. Close deals. Support customers. Ship products. Meet deadlines.
Success metrics:
- Deals closed
- Customers supported
- Features shipped
- Deadlines met
Acceptable tradeoff: Some security risk in exchange for productivity. The user shouldn't feel "This security policy is destroying my ability to work."
Risk assessment: Overweight productivity losses (every MFA prompt interrupts flow). Underweight security failures (breaches seem abstract, haven't happened to me).
Personally affected: Experience every friction point. Every blocked access attempt. Every additional authentication step. Every timeout from policy enforcement.
The Inevitable Collision
Security team implements policy that seems reasonable:
- "Require MFA from new locations" (prevents credential compromise)
- "Block access from unmanaged devices" (prevents data leakage)
- "Deny privileged access outside business hours" (reduces attack window)
Users experience policy as obstacle:
- "I can't work from client site because policy blocks me"
- "I can't check email from phone because device not managed"
- "I can't fix production issue at 9 PM because policy denies access"
Security team sees: Risk mitigation, compliance, protection. Users see: Blocked from doing their jobs.
Both perspectives are valid. Both are incomplete. Sustainable security requires considering both.
The Common UX Failures
Here are the context-based access policies that consistently create user experience problems:
Failure 1: MFA Fatigue from Over-Aggressive Policies
The policy: MFA required for access from any new network or location.
The security logic: New network might mean compromised device on coffee shop wifi or attacker accessing from foreign country. Additional verification makes sense.
The user experience:
Sales rep drives to client site. Connects to client wifi. MFA prompt.
Leaves client, drives to lunch, connects to restaurant wifi. MFA prompt.
Returns to client for afternoon meeting, different conference room, different wifi network. MFA prompt.
Leaves client, goes to airport for flight home. MFA prompt.
Lands, connects to home wifi. MFA prompt.
Five MFA prompts in one day. Same person, same device, all legitimate access. But policy sees "new network" five times and demands verification five times.
What happens:
- User keeps approving MFA without looking (prompt fatigue)
- Attacker sends MFA prompt, user approves reflexively, attack succeeds
- Or user finds workaround (forwards to personal email, uses personal device)
- Security measure becomes either ineffective or counterproductive
The fix: Define "new location" more intelligently. Same city in same day = not new location. Same country for 24 hours = not new location. Require MFA for genuinely unusual patterns (new country, weeks since last access), not every network change.
Failure 2: Device Compliance That Breaks Mobile Work
The policy: Access to corporate applications requires device enrolled in MDM and meeting compliance requirements.
The security logic: Managed devices are encrypted, patched, remotely wipeable. Unmanaged devices might be compromised. Only managed devices should access corporate data.
The user experience:
Executive traveling to conference. Wants to check email from phone during taxi ride. Phone enrolled in MDM because IT insisted when executive got it.
MDM reports: "Device not compliant - OS update required."
Executive hasn't installed latest iOS update. Phone now blocks email access.
Executive in taxi, can't install 2GB iOS update over cellular. Can't access email. Misses critical message about meeting change. Shows up to wrong location.
What happens:
- Executive bypasses policy (forwards to personal email)
- Or executive forces IT to create exception
- Or executive ignores MDM compliance entirely going forward
- Policy creates more risk than it prevents
The fix: Graduated compliance, not binary pass/fail. Major compliance issues (no encryption, jailbroken device) block access. Minor issues (OS one version behind) allow access with warning and deadline for remediation.
Failure 3: Geographic Restrictions That Block Legitimate Travel
The policy: Block access from countries where company doesn't operate.
The security logic: No employees in Russia/China/North Korea. Access from those countries is probably malicious. Safe to block.
The user experience:
Sales rep books last-minute trip to close deal in Singapore. Company has no Singapore office, Singapore is on "block list" created when security team copied list of "high-risk countries" from internet.
Sales rep lands in Singapore. Can't access Salesforce, email, or presentation materials. Can't close deal. Loses $500K opportunity because can't access sales tools.
Emergency exception takes 6 hours to process (IT in different timezone, asleep). Deal already lost.
What happens:
- Deal lost, revenue impacted
- Sales team demands geographic restrictions removed entirely
- Security team loses credibility
- Policy gets disabled
The fix: Block only countries where you truly have zero business (sanctioned countries, known threat sources). For everywhere else, use MFA for new countries instead of blocking. Inconvenient but not preventing work.
Failure 4: Time-Based Restrictions That Break On-Call
The policy: Deny privileged access to production systems outside scheduled maintenance windows.
The security logic: Most breaches happen off-hours. Restricting privileged access outside approved windows reduces attack surface.
The user experience:
Production database crashes at 2 AM Saturday. On-call engineer gets paged. Tries to access database admin console to diagnose issue. Access denied - outside maintenance window.
Engineer tries to access deployment tools to rollback bad change. Access denied.
Engineer tries to access monitoring dashboards with elevated permissions. Access denied.
Outage extends from 2 hours (if engineer could access immediately) to 8 hours (until Monday morning when maintenance window opens and policy allows access).
What happens:
- Customer impact increases 4x
- SLAs violated
- Engineering team demands policy reversal
- On-call becomes impossible
- Policy disabled
The fix: Allow privileged access outside maintenance windows but require additional verification (second approver, hardware token MFA, detailed justification). Add friction for off-hours admin access without blocking it entirely.
Failure 5: Network-Based Restrictions That Prevent Remote Work
The policy: Administrative access to infrastructure only allowed from corporate network. VPN or in-office required.
The security logic: Corporate network has monitoring, DLP, security controls. Direct internet access bypasses controls. Everything should go through corporate network.
The user experience:
Engineer working from home coffee shop. VPN connection unstable on coffee shop wifi. Keeps dropping. Every VPN disconnect triggers reauthentication.
Trying to deploy code to production. VPN drops mid-deployment. Deployment fails halfway. System in inconsistent state. Can't reconnect fast enough to fix.
Home internet goes down. Engineer tries to hotspot from phone. VPN on phone drains battery, is even more unstable than laptop VPN.
Engineer gives up, drives to office, deploys from there. 2-hour commute for 10-minute deployment because VPN policy made remote deployment impossible.
What happens:
- Remote work becomes impractical
- Engineers required to come to office for deployments
- Or engineers find workarounds (personal cloud accounts, shadow IT)
- Flexibility destroyed, policy circumvented anyway
The fix: Strong authentication instead of network restrictions. If user authenticated with MFA, device compliance verified, from known location, allow direct access. VPN for legacy systems that truly require it, not for everything.
The Real Cost of Friction
User experience problems with context-based access policies aren't just annoying. They have measurable business costs:
Direct Productivity Loss
Time spent dealing with authentication:
- MFA prompt 5 seconds to complete
- 15 prompts per day per user (aggressive policy)
- 75 seconds per user per day
- 200 users
- 15,000 seconds = 4.2 hours per day company-wide
- 21 hours per week
- ~1,000 hours per year just completing MFA prompts
At $100/hour average fully-loaded cost, that's $100,000 per year in direct authentication overhead.
Time spent on workarounds:
- Policy blocks legitimate access
- User finds workaround (forward to personal email, VPN reconnection, etc.)
- 10 minutes per day per affected user
- 50 users affected daily
- 500 minutes = 8.3 hours per day on workarounds
- ~2,000 hours per year
At $100/hour, that's $200,000 per year on workarounds.
Time IT spends on exceptions:
- Policy blocks user, user submits exception request
- IT investigates, approves/denies, implements exception
- 30 minutes per exception
- 10 exceptions per week
- 260 hours per year
At $150/hour IT cost, that's $39,000 per year on exception handling.
Total direct cost: $339,000 per year for 200-person company.
Opportunity Cost
Revenue impact:
Sales rep blocked from accessing Salesforce at client site. Can't close deal. Deal delayed or lost.
- 5 deals delayed per year
- Average deal size: $200,000
- 30-day delay costs (time value, risk of losing deal)
- Estimated impact: $100,000-$500,000 per year
Engineer can't deploy fix for production issue because VPN policy blocks off-hours access.
- 3 incidents per year extended by 4 hours due to access restrictions
- Customer impact, SLA violations, reputation damage
- Estimated impact: $50,000-$200,000 per year
Innovation impact:
Engineers find security policies so onerous they avoid deploying new features to avoid authentication friction.
- Deployment frequency drops
- Innovation slows
- Competitive advantage erodes
- Impact: Difficult to quantify but real
User Satisfaction and Retention
Internal NPS/satisfaction:
"How likely are you to recommend working here to a friend?"
Before aggressive policies: +40 NPS After aggressive policies: +15 NPS
Satisfaction drop correlates with talent retention. Top performers leave because "can't get work done."
Hiring impact:
"Our security policies make it impossible to work remotely" becomes part of company reputation. Harder to recruit remote talent.
Shadow IT and Workarounds
Users forward work to personal email: Now corporate data in Gmail accounts outside IT control.
Users share credentials: "IT won't give you access? Use my account." Now no attribution for actions.
Users use personal devices: Policy blocks corporate device, work continues on unmanaged device. Policy creates exactly the risk it was meant to prevent.
Security debt increases: Workarounds harder to secure than legitimate access paths. Policy drives users to less secure alternatives.
Measuring User Experience Impact
Before implementing context-based policies, measure baseline. After implementing, measure change. You need data to justify security measures that create friction.
Quantitative Metrics
Authentication time:
- Time from login initiation to successful access
- Baseline: 5 seconds average
- With aggressive MFA: 30 seconds average
- 25-second increase × users × frequency = total time cost
Exception request volume:
- Exceptions requested per week
- Baseline: 2 per week (normal IT requests)
- With new policy: 25 per week
- 23 additional exceptions = policy blocking legitimate work
Help desk tickets:
- "Can't access X" tickets per week
- Baseline: 10 per week
- With new policy: 40 per week
- 30 additional tickets = user confusion or policy failures
VPN performance:
- Connection success rate
- Average throughput
- Disconnect frequency
- Before VPN-required policy vs after
Time to resolution for incidents:
- How long to fix production issues
- Baseline: 1.5 hours average
- With access restrictions: 3 hours average
- 2x increase in incident duration = real business impact
Qualitative Feedback
User surveys:
"How often do security policies prevent you from doing your job?"
- Never: 10%
- Rarely: 20%
- Sometimes: 40%
- Often: 25%
- Always: 5%
If 30% say "often" or "always," policy is too restrictive.
"How much time per day do you spend dealing with authentication and access restrictions?"
- <5 minutes: Acceptable
- 5-15 minutes: Borderline
- 15+ minutes: Too much friction
Specific incident reports:
"Tell us about a time security policies prevented you from doing something important."
Sales rep: "Couldn't access customer data during meeting, lost deal." Engineer: "Couldn't deploy fix because VPN wouldn't connect, outage extended 4 hours." Executive: "Missed critical email because phone compliance blocked access."
Collect stories. These reveal impact that metrics miss.
Tracking Over Time
Don't measure once. Track trends:
Week 1: Exception requests: 5 Week 2: Exception requests: 15 Week 3: Exception requests: 30 Week 4: Exception requests: 50
Exponential growth in exceptions = policy fundamentally misaligned with work patterns.
Month 1: Help desk tickets: 12 Month 2: Help desk tickets: 8 (users learned) Month 3: Help desk tickets: 25 (new edge cases) Month 4: Help desk tickets: 40 (policy becoming unworkable)
Initial drop as users learn, then increase as edge cases accumulate = policy has systemic problems.
Balancing Security and Productivity
The goal isn't maximum security. The goal is appropriate security that people can actually work with.
The Friction Equation
Security value must exceed friction cost.
High security value, low friction: Implement immediately.
- Example: SSO with MFA once per day
High security value, high friction: Implement carefully with mitigation.
- Example: Managed devices for sensitive apps, but allow read-only from unmanaged
Low security value, low friction: Consider implementing.
- Example: Password complexity requirements
Low security value, high friction: Don't implement.
- Example: MFA for every application every time
Risk-Proportional Friction
Different applications warrant different friction levels:
High-risk applications (production, finance, HR, customer PII):
- MFA every time
- Managed devices only
- Network restrictions
- Time-based restrictions
- High friction justified by high risk
Medium-risk applications (most business apps):
- MFA on new device/location
- Managed devices preferred, unmanaged allowed with restrictions
- Location monitoring without blocking
- Moderate friction for moderate risk
Low-risk applications (email, chat, calendars):
- MFA once per session
- Any device allowed
- Minimal restrictions
- Low friction for low risk
Don't apply high-risk controls to low-risk applications.
User Role Considerations
Different roles have different tolerance for friction:
Executives and sales:
- High travel, high need for mobile access
- Low tolerance for friction (revenue impact)
- Allow more flexibility, rely on monitoring and anomaly detection
Engineers and operations:
- Need privileged access, often off-hours
- Medium tolerance for friction (understand security rationale)
- Additional verification for elevated access, not blocking
Finance and HR:
- Access sensitive data, usually from predictable contexts
- High tolerance for friction (compliance requirements)
- Stricter controls acceptable
Policies should consider who they affect and what those users need to accomplish.
The Workaround Test
If users find workarounds to your policy, policy is too restrictive.
Users forwarding corporate email to Gmail? Email policy too restrictive.
Users sharing credentials to avoid access requests? Provisioning too slow or restrictive.
Users using personal devices because corporate devices blocked? Device policy too restrictive.
Workarounds indicate policy-reality mismatch. Fix policy, don't blame users.
Testing That Includes UX
Standard security testing focuses on "does policy block attacks?" Also need: "does policy block legitimate work?"
Report-Only Mode
Before enforcing policy, run in report-only mode for 2-4 weeks.
What you learn:
- Who would be blocked
- How often policy triggers
- Which users affected most
- Which applications affected most
- What "edge cases" actually exist
Example findings:
Policy: "Block access from outside US"
Report-only shows:
- 15 employees regularly access from Canada (remote workers)
- Sales team travels to Mexico quarterly (conferences)
- Support team in Philippines (24/7 coverage)
- CEO travels internationally monthly
Enforcement without revision would block 30+ people. Report-only prevents disaster.
Pilot with Diverse Roles
Don't pilot with IT team only (IT has exceptions, doesn't represent typical users).
Pilot group should include:
- Sales (travel-heavy, mobile-dependent)
- Support (off-hours access, varied locations)
- Engineering (privileged access, off-hours deployments)
- Regular office workers (baseline experience)
- Executives (high visibility, low tolerance for friction)
Get feedback from all roles before broad rollout.
Measure Pilot UX Impact
During pilot, track:
- How often were you blocked from legitimate work? (count)
- How much time did you spend on authentication? (minutes per day)
- Did policy prevent you from meeting deadlines? (yes/no + details)
- What workarounds did you find? (what and why)
If pilot reveals high friction, refine before broad rollout.
Iterate Based on Feedback
Pilot isn't validation. Pilot is learning.
Pilot reveals: Sales team blocked from client access 3x per week.
Response: Refine policy to allow access from business locations (not just corporate office).
Second pilot: Sales team still blocked occasionally but much less (1x per month).
Response: Acceptable. Proceed with rollout.
Don't defend initial policy. Adjust based on real usage patterns.
Communication That Actually Works
How you communicate context-based policies affects user acceptance.
Bad Communication
Email from IT:
"Effective immediately, MFA is required for all access from new locations. This is for security. No exceptions."
User interpretation:
- Another IT policy making my life harder
- IT doesn't understand my work
- No explanation of why
- No consideration of impact on me
- I'll find workaround
Result: Resistance, circumvention, resentment.
Better Communication
Email from security team:
"We've had 3 credential compromise attempts in the last quarter from attackers in foreign countries. To protect against this while minimizing impact on legitimate work, we're implementing MFA for access from countries where we don't have employees. This means:
- US/Canada/Mexico: No additional MFA (where 95% of our team works)
- Other countries: MFA on first access from that country
- If you travel internationally for work, you'll get one MFA prompt when you arrive, then normal access
We tested this with 20 volunteers across sales, engineering, and support. Average additional authentication time: 30 seconds per international trip.
If you travel frequently and this creates problems, let us know. We can create exceptions or refine the policy."
User interpretation:
- Real security threat we're addressing
- Considered my impact
- Tested before deploying
- Willing to adjust if problems
- Legitimate security, thoughtful implementation
Result: Acceptance, compliance, cooperation.
Key Communication Elements
Explain WHY: Not "we require MFA." But "we've had credential compromises, MFA prevents this."
Show you tested: Not "implementing new policy." But "tested with 20 users, refined based on feedback, now rolling out."
Acknowledge impact: Not "this is for security." But "this will add 30 seconds per international trip, we've tried to minimize friction."
Offer exceptions: Not "no exceptions." But "if this doesn't work for your role, let us know."
Provide support: Not "figure it out." But "here's how to set up MFA, here's who to contact with problems."
Ongoing Communication
Don't communicate once and forget.
Week 1: Policy announcement, explanation, training.
Week 2: "How's it going?" survey. Collect feedback.
Week 3: "We heard feedback about X, here's what we're changing."
Month 2: Usage statistics. "Policy blocked 25 attack attempts, required 0 exceptions for legitimate work."
Quarter 1: Review and refine. "Based on 3 months of data, we're adjusting Y."
Show users you're monitoring impact, responding to feedback, refining continuously.
When to Roll Back
Sometimes context-based policy just doesn't work. Recognize when to roll back:
Roll Back If:
Exception volume exceeds 20% of users: Policy blocking 1 in 5 users = fundamentally misaligned with work patterns.
User complaints become overwhelming: Help desk drowning in policy-related tickets = policy creating more work than it prevents.
Critical business impact: Deals lost, incidents extended, executives threatening jobs = friction exceeds security value.
Workarounds become systemic: Most users finding ways around policy = policy creating shadow IT instead of security.
Better alternatives exist: Different approach achieves same security with less friction.
Don't Roll Back If:
Small number of vocal complainers: 5 users complaining loudly doesn't mean policy wrong. Measure actual impact.
Initial adjustment period: First week friction might be learning curve, not fundamental problem. Give it 2-4 weeks.
Complaints without alternatives: "I don't like this" without "here's what would work better" isn't actionable.
Security value clear and high: If policy preventing actual attacks with minimal false positives, friction might be justified.
How to Roll Back Gracefully
If rolling back:
- Acknowledge honestly: "We implemented X for security. Based on feedback, friction exceeds value. We're rolling back."
- Explain learnings: "We learned our travel patterns are more distributed than we thought. Policy doesn't match our reality."
- Describe alternative: "Instead of blocking foreign access, we'll use enhanced monitoring and MFA for unusual patterns."
- Thank participants: "Thanks to everyone who provided feedback. This helps us implement security that actually works."
Don't defend failed policy. Learn and adjust.
The Balance Is Possible
Context-based access control can add meaningful security without destroying user experience. But it requires:
Understanding actual access patterns: Can't create policies for patterns you've never observed. Need visibility into who accesses what, when, from where, using which devices.
Zluri's access management platform provides this visibility across your application portfolio—enabling policy creation based on real usage, not assumptions.
Book a demo to see how visibility into access patterns prevents creating policies that break workflows.
Measuring user impact: Track friction, not just security metrics. Time spent on authentication, exceptions requested, incidents extended by policies.
Testing before enforcing: Report-only mode, pilot groups, diverse roles, iteration based on feedback.
Communicating thoughtfully: Explain why, show you tested, acknowledge impact, offer support and exceptions.
Refining continuously: Policies aren't set-and-forget. Monitor impact, collect feedback, adjust based on data.
Accepting tradeoffs: Perfect security that prevents work is worse than good security that allows work. Appropriate security for actual risks.
Your security team wants to protect the company. Your users want to get work done. These goals aren't contradictory. They're complementary when you implement security that respects user reality.
The goal isn't security at any cost. The goal is security people can actually work with.
Frequently Asked Questions
What is context-based access control?
Context-based access control evaluates signals beyond identity — location, network, device compliance, time of day, behavior patterns — before granting access. Instead of "is this the right user," it asks "is this the right user, under the right conditions." A login from a managed laptop in the office gets treated differently from the same credentials used at 2 AM from an unfamiliar country.
Why do context-based access policies frustrate users?
Because policies trigger on legitimate variation in how people actually work. Sales reps switch networks five times a day. On-call engineers need production access at 2 AM. Executives travel internationally. Policies built on assumptions — "new network = suspicious," "off-hours = risky" — punish normal work patterns, and users experience that as being blocked from their jobs.
What is MFA fatigue and why does it matter?
MFA fatigue is when users get prompted so frequently they start approving prompts reflexively, without checking. This defeats the security purpose entirely — an attacker can push an MFA prompt and the fatigued user approves it on autopilot. Over-aggressive policies that prompt on every network change are the most common cause.
How do I measure whether a policy creates too much friction?
Track four signals: exception request volume (if it exceeds ~20% of users, the policy is misaligned with real work patterns), help desk tickets mentioning blocked access, authentication time per user per day (15+ minutes is too much), and incident resolution time before vs. after the policy. Pair the numbers with qualitative reports — specific stories of blocked deals or extended outages reveal impact metrics miss.
Should I block access from foreign countries entirely?
Only for countries where you genuinely have zero business — sanctioned countries or known threat sources. For everywhere else, require MFA on first access from a new country instead of blocking. Blocking breaks last-minute business travel; MFA adds 30 seconds. The security value is similar, the friction difference is enormous.
What's the right way to roll out a context-based policy?
Run it in report-only mode for 2–4 weeks first to see who would be blocked and why. Then pilot with a diverse group — sales, support, engineering, executives — not just IT, who usually have exceptions and don't represent typical users. Measure friction during the pilot, refine the policy, then enforce broadly with clear communication about why it exists and what to do when it blocks legitimate work.
When should a security policy be rolled back?
Roll back when exception volume exceeds 20% of users, workarounds become systemic (mass forwarding to personal email, credential sharing), or critical business impact accumulates — lost deals, extended outages. Don't roll back over a handful of vocal complaints or first-week adjustment friction; give a policy 2–4 weeks and measure actual impact before deciding.
How does Zluri help with context-based access control?
You can't write sensible policies for access patterns you've never observed. Zluri gives visibility into who accesses which applications, when, from where, and on which devices — so policies get built on real usage data instead of assumptions that end up blocking your own sales team.
.svg)
