Here’s the uncomfortable truth: Zero Trust is not the strongest security model. And giving every user total freedom isn’t the most productive option either. Both extremes are broken. If your M365 setup leans too far in either direction, you’re leaving gaps—or grinding productivity to a halt. In this workshop, I’ll show you how top-performing organizations hit the sweet spot: a perfectly tuned system where CISO, GDPR officer, and everyday user are all satisfied. The tradeoffs may surprise you, and the solution usually isn’t where most IT pros start looking.
Why Extremes Always Fail
What happens if you go all in on Zero Trust or let users roam free with unlimited access? In practice, both of those choices end up creating more problems than they solve. On paper, Zero Trust looks perfect—it promises a world where every access request is inspected, validated, and logged. Nothing moves without constant checks. The framework sounds airtight, and security teams love the neat diagrams vendors put in front of them. But the reality of running it inside a production environment hits much harder. Each one of those trust decisions translates into real policies, prompts, and denials that ordinary employees need to fight against just to get their work done.
Think about what it feels like for someone on the marketing team trying to launch a campaign under strict rules. Every time they log in, they’re hit with extra verification screens. They try sharing a file externally, and it bounces back. They go to approve an ad buy, but the system blocks the unfamiliar IP of the agency. Before long they’ve spent more time emailing IT than working. What looked like “tight security” in a governance meeting turns into delayed projects, frustrated staff, and managers asking why everything takes twice as long now.
It’s the digital version of walking through an office where every single door has its own unique key. Not only do you need to carry a giant ring with dozens of keys, but you’ll also end up stuck in hallways because you can’t find the right one. In theory, each door has its own lock, so only the right people get in. In practice, people end up propping doors open with chairs just to move around and do their jobs. That’s not better security, it’s a workaround created by frustration, and it undermines the whole system.
Now look at the opposite extreme where every user enjoys total freedom. Maybe IT is tired of approvals, so they just hand out admin rights across the board. At first, it feels amazing. Install whatever you need, fix your own problems, no more waiting. But it doesn’t take long before an employee clicks the wrong link, installs infected software, and suddenly ransomware is encrypting shared drives. The same freedom that felt empowering quickly turns into a wildfire spreading through systems that were supposed to stay protected. By giving everyone a key to the entire building—including the server room—you’ve essentially invited attackers to do whatever they want with no barriers in place.
Plenty of IT teams have lived through both of these scenarios. Some remember the six-month Zero Trust rollout that clogged workflows so badly that leadership demanded half the rules be rolled back. Others remember the “everyone’s an admin” decision that ended with entire environments rebuilt from backup after an attack. Both groups reach the same conclusion: there’s no shortcut where you simply pick one side and declare victory. These extremes consume countless hours, either by dragging down productivity or by forcing frantic damage control after a breach.
It’s a natural question—if each approach fails, why can’t we just optimize one until it works? The trouble is that the system doesn’t allow it. Security, compliance, and usability are tied together like communicating vessels. Strengthening one without regard for the others just shifts the pressure around until something bursts. If you crank security to the maximum, workflows collapse. If you open access to the point of ease and comfort, risk spills over everywhere. Neither model can hold on its own because the environment wasn’t built for absolutes—it was built with interconnections across identity, applications, and endpoints.
So the message becomes clear. Balance isn’t some optional luxury you add when time allows. It’s the operating principle required by the way these systems are designed to function. Extreme security breaks people. Extreme freedom breaks systems. The sustainable approach is finding that middle path where policies protect without paralyzing, and where productivity thrives without opening major attack surfaces.
And while theory often talks in big frameworks, most organizations don’t fall apart at that high level. They break first in the day-to-day execution. The settings that promise safety often live hidden away in the very tools administrators use. Which means if you want to see where the balance tips too far, you need to look at the admin portals.
The Hidden Impact of Admin Portals
The most overlooked place where security clashes with productivity is sitting right in front of admins every day—the portals. Most end users will never log into them, but the settings chosen there ripple through everything they touch. The Teams call that won’t connect, the Outlook sign-in that suddenly stops, even OneDrive sync failing out of nowhere—underneath almost every one of those headaches is a portal configuration someone changed thinking it was a small tweak. For admins, toggling one control feels harmless. For the user base, that one toggle can rewrite an ordinary workday in ways that nobody predicted.
It’s easy to forget how tightly connected these portals really are. An admin working late might tighten up a sharing policy in SharePoint Online. They’re thinking they’ve just blocked risky external access. The next morning, a legal team trying to send draft contracts to outside counsel discovers their links don’t work. Marketing drops a file into Teams for a partner and sees an access denied screen. Everyone assumes the system is broken, but the only thing that happened was a checkbox click that cascaded into dozens of blocked scenarios. That disconnect between intention and result is where frustration begins to grow.
It helps to picture it like making an adjustment to your car’s steering wheel, only to find out afterward that the brake pedal stopped responding. The changes don’t live in isolation. In M365, one security control can silently overlap with another, creating side effects even the admin didn’t expect. You thought you were just tightening steering to make the drive safer, but you can’t bring the car to a stop. That’s how quickly a well-meant setting becomes a problem that pulls attention away from actual business goals.
Most administrators don’t set out to make life harder for their users. They’re following best practice guides, running compliance checks, and responding to pressure from the security side. The misstep is treating policies like isolated switches instead of system-level dials. It’s the difference between turning down a single light in a room versus rerouting the building’s entire power system. The action is simple, and it feels like a win in the admin interface, but the outcome is far bigger than the admin ever sees on their screen.
Take something as basic as Multi-Factor Authentication prompts. Adjusting them looks straightforward—you decide that push approvals should trigger more often, so you raise the frequency. In the portal, the change looks minor, almost invisible. The knock-on effects, though, land with travelling employees who suddenly find themselves locked out of their mailbox in the middle of an airport lounge, unable to clear the prompt because they don’t have stable connectivity. Support tickets flood in, productivity slides, and all of a sudden the extra safety you introduced to increase trust is being treated as a nuisance bordering on a system outage.
From a CISO’s chair, that policy change might look wonderful. More prompts mean a stronger barrier against credential abuse and better numbers to report back to the board. From the perspective of the employees, however, the same change feels like a tax on every single login. You wanted friction for the attacker, but the person feeling it every hour of the day is your own staff. That’s the imbalance many organizations stumble into—the goals of security appear aligned on paper, but the human side is paying the actual cost with frustration and time lost.
When you look at it this way, it becomes obvious that portals aren’t neutral tools. They either amplify productivity or suppress it, depending on whether settings complement each other or clash. Treating them as a collection of simple toggles underestimates the ripple effect each one has. The truth is, every change shifts the whole system, even if the designer didn’t intend it to. The challenge isn’t picking the most secure checkbox; it’s predicting the interplay between those checkboxes across SharePoint, Exchange, Teams, and identity policies.
Optimizing the portals means shifting the mindset away from isolated settings and toward viewing them as a network. A decision that helps security in one corner isn’t a real win if it blocks three workflows in another. What matters is making the settings work together so employees can move without hitting constant obstacles. When that balance is struck, users often don’t even notice the portals exist at all—which is the real mark of success. Security is operating in the background, compliance can pass an audit without drama, and no one feels like they’re battling their tools just to meet a deadline.
That’s why the portals become such a critical battleground. Ignore their role, and you end up with accidental roadblocks. Treat them as interconnected, and you unlock the very balance between safety and efficiency that everyone is chasing. But of course, portals are only the first layer. The real tension surfaces in how Conditional Access policies are designed, and that’s where things can either hold together or fall apart fast.
Conditional Access: When Security Collides with Workflow
What if a single rule in Conditional Access could knock out three completely different workflows at once? That’s not a hypothetical—it’s something many teams have already lived through. Conditional Access is marketed as a way to give precision. You define who can access what, under which conditions, and the system does the rest. On paper, it looks like an elegant solution for the problem of balancing control with user productivity. But in reality, the rules can be so tightly bound that they end up strangling the very processes they were meant to protect. What starts off as a quick security win can easily turn into a web of blocked logins, disconnected apps, and frustrated support calls.
Picture a scenario where your organization decides it’s too risky to allow sign-ins from outside a trusted IP range. It seems like a straightforward policy: block everything that doesn’t come from the corporate network. IT checks the box in Conditional Access, confident that this will cut down on suspicious traffic. The next morning, half the workflows in the business buckle. Marketing is suddenly locked out of tools needed to run digital campaigns from partner offices. Legal can’t review contracts with clients overseas because external sign-ins are blocked by design. Finance opens its reporting dashboards while traveling and gets nothing but access denied. One policy, three departments brought to a standstill.
This ripple effect is what makes Conditional Access so tricky. The more rules you pile on, the more fragile the environment becomes. Each department relies on connections the admin didn’t think about when designing the rules. When you pull the security rope too tight, workflows snap under the weight of restrictions. It’s the paradox that admins face every day—the very policies designed to keep people safe can be the ones that bring their work to a screeching halt. Instead of more control, you get more breakage, and every broken connection turns into yet another ticket for IT to untangle.
The financial impact of these disruptions isn’t small either. Studies tracking downtime costs have shown again and again that interruptions in business-critical systems can cost more per hour than a typical breach event. That doesn’t mean security isn’t important—it just underlines that rules set without considering workflow cost can backfire badly. A policy that blocks international logins might cut down on risk at the edge, but if it cancels out an entire day of productivity for multiple teams, the net result is a loss. You’re safe from one threat, but you’ve opened the door to another problem: a company that can’t function when it needs to.
And here’s the irony. As controls tighten, users often look for routes around them. Block access to tools outside the corporate IP, and employees start connecting through personal email accounts or unapproved file-sharing platforms just to get work moving again. In trying to kill one form of risk, you’ve unintentionally encouraged shadow IT, which carries a whole new set of dangers. When users feel the legitimate path is blocked, they don’t always stop working—they just find a new path, and it usually comes without visibility, logging, or protection. So the intent of Conditional Access ends up flipped on its head, fueling behavior that’s harder to monitor and secure than before.
Does that mean Conditional Access is a mistake? Not at all. The power isn’t in adding harder rules, it’s in writing smarter ones. That means aligning policies with the real ways people work rather than the fears of what might happen in the background. Instead of a blanket location block, you design exceptions for trusted partners who need external access. Instead of hammering every login with an MFA prompt, you combine risk-based conditions that only escalate when the system sees unusual activity. It’s about shaping a set of rules that adapt to workflows instead of destroying them. Security doesn’t have to mean endless friction—not when the rules serve the people actually using the system.
When done right, Conditional Access becomes a safety net, not a cage. It strengthens the environment by providing flexibility and resilience at the same time. But even if you get those rules perfectly tuned, there’s still another point where things break down. The distribution of admin rights often causes just as much tension. And that’s why the next big question becomes: how do you manage admin roles without creating either giant risks or massive bottlenecks?
PIM Without the Pain
What if you could work as an admin with all the power you need but never actually hold global admin rights? That’s not a trick question—it’s exactly the kind of balance modern IT setups are trying to get right. Historically, admins have only had two choices. Either you’re sitting on permanent, high-level access that makes you a prime target for attackers, or you live in constant friction, spending half your day waiting on someone to approve the elevated access you need just to do your basic job. Both setups sound familiar, but neither one actually works well when put to the test.
Consider the first option: constant, unrestricted global access. It feels convenient at first. You don’t have to think about permissions, you just get the job done. Need to reset a tenant-wide policy? You’ve got it. Need to change a global setting? No problem. The downside doesn’t show up until much later, usually in the middle of an incident. If that account gets phished or taken over, the intruder doesn’t just have a little control—they have the whole environment under their fingertips. It’s one of the fastest ways to hand over the keys to the entire kingdom, and plenty of organizations have learned the hard way how costly that mistake can be.
Now look at the other extreme. You strip away all standing admin rights so that nobody carries more access than they absolutely need. In theory, this gives you a smaller attack surface, which sounds ideal. But what happens when a system outage hits at two in the morning? The helpdesk team scrambles to bring services back online but realizes their admin privileges are gone. They submit requests, ping managers, wait for approvals, and in the meantime, the outage drags on. Everyone is frustrated—the users stuck without access, the helpdesk team whose hands are tied, and the managers caught in the approval workflow. The result might be technically secure from an attacker’s perspective, but operationally, it’s a complete bottleneck.
I once saw a scenario where a team needed to reset authentication services during a live outage. The admins tried three different approval paths before finally reaching someone on-call who could grant them access. By that point, users had been offline for hours, the service desk had a backlog of tickets, and tempers were flaring across the company. That’s when it becomes obvious: total lockdown doesn’t equal stability. It only trades one risk for another—the risk of being unable to act when the system most urgently demands it.
This is where Privileged Identity Management, or PIM, steps in. PIM offers a middle ground, not by watering down admin access, but by transforming how and when it’s granted. With PIM, you don’t walk around holding permanent global admin power. Instead, you request the rights you need at the moment you need them, and the system lifts your permissions temporarily. When the task is finished, those rights expire automatically. It’s access on-demand without dangling permanent credentials in front of attackers.
The payoff is huge. From a risk standpoint, you’ve massively reduced the surface area. Attackers who manage to compromise an account won’t find golden keys lying around because those keys only exist during controlled windows. From an agility standpoint, admins still get what they need without waiting hours for a chain of approvals. It turns high-stakes incidents into manageable events because the right people can elevate rights instantly, do the fix, and move on.
Users feel this change too, even if they’re not aware of the mechanics behind it. Less downtime means fewer support tickets clogging the queue. Faster fixes mean they’re not left hanging while IT chases after permissions. Escalations drop because issues actually get closed on the first pass. That sense of reliability translates into better trust in IT overall—not because admins advertise that PIM is behind the scenes, but because users experience smoother outcomes.
And when compliance officers or CISOs weigh in, the model works in their favor too. PIM delivers complete logs of who requested what, when, and why, which looks great during audits. GDPR requirements around accountability are satisfied because access can be tied back to specific, time-bound requests. Admins no longer dread needing more rights, CISOs don’t panic about overly broad powers, and compliance teams get the detailed reporting they crave. In other words, one configuration satisfies three competing voices at once.
That’s the real beauty of PIM. It proves you don’t have to sacrifice safety for agility. With the right setup, the entire system benefits—from end users to compliance teams—because the model balances out the risks and the workflows without tipping too far in either direction. And that brings us back to the bigger picture: the system only works when all three perspectives—security, compliance, and usability—line up together.
The System Everyone Has to Agree On
Here’s the real test most organizations never ask out loud: if you lined up the CISO, the GDPR officer, and an everyday user at the same table, would all three cheer for the way your environment is configured? It sounds almost impossible because each role seems wired to want the opposite of the others. The CISO is chasing proof of airtight controls and risk reduction. The GDPR officer scans for anything that could expose personal data or compliance gaps. And the end user just wants single sign-on to work without constant interruptions. When you step back, the system looks less like a clean architecture diagram and more like three people pulling at different ends of the same rope.
The way it typically plays out is predictable. Security pushes for stricter access layers, but then the user base groans about delays and never-ending authentication checks. Compliance looks at the same setup and calls it leaky because the logging doesn’t give enough detail to satisfy regulations. The poor employee caught in the middle is clicking through multi-factor prompts half a dozen times each morning, asking why the VPN keeps disconnecting, and wondering why their “simple” job now requires a mini degree in IT support. Nobody walks away happy. The feedback loops become toxic—users blame IT, IT blames security mandates, and leadership wonders why productivity stats keep shrinking.
The mistake is assuming that these three forces—security, compliance, and usability—must operate in tension. That’s how most organizations treat it: pick two and sacrifice the third. Strong compliance usually means painful friction on the user side. Smooth user experience often looks suspicious to security specialists because it feels too easy. But that tradeoff mindset misunderstands how modern systems actually interact. You don’t achieve balance by slicing away features until everyone is equally dissatisfied. Balance happens when the design allows each part to reinforce the other. Think less “compromise” and more “harmony.”
It’s like an orchestra tuning before a performance. The violin doesn’t go silent just so the flute can be heard. Neither does the percussion overpower every other section. Each instrument plays its part, but never to the point of drowning out the rest. If the sound engineer only paid attention to volume levels in isolation, the result would be chaos. Instead, the goal is collective alignment—fine adjustments that let every section be heard in balance. Admin decisions, policy rules, and compliance checks operate in the same way. Viewed individually, they look like competing notes. Viewed together, they can create clear, steady music.
I’ve seen a mid-sized organization nail this balance almost by accident. They were struggling with poor audit results and miserable user sentiment after tightening a set of Conditional Access policies. Instead of doubling down, they did a full review that combined admin settings, CA, and PIM configuration under one lens. By allowing on-demand admin rights while shifting authentication prompts to risk-based triggers, they surprised themselves. Day-to-day user complaints about “always getting locked out” dropped by nearly half in a single quarter. At the same time, the annual compliance audit gave them their best score to date. Security didn’t feel watered down—if anything, the logging and just-in-time access gave them tighter oversight. What looked like concessions from one angle turned out to be gains across the board.
When systems run in that mode, something curious happens. The best compliment you can get isn’t applause—it’s silence. Employees stop talking about sign-in issues. Managers no longer escalate helpdesk complaints. Compliance stops pinging IT for missing records because the audits pass with minimal effort. The paradox is that success becomes invisible. If everyone notices the system, it usually means something is broken. If no one notices, it’s because security, compliance, and usability are aligned, quietly reinforcing each other. That’s not a fragile compromise, it’s equilibrium.
When all three of those perspectives—CISO, GDPR officer, and user—coexist without constant friction, you’ve moved beyond survival mode. You’ve stepped into a configuration that is not only technically sound but socially sustainable inside the organization. That’s the real metric of success, because a secure system that people hate to use will not survive, and a smooth system that flunks compliance audits won’t either. The sweet spot is where every role sees its needs being met without undercutting the others.
But here’s the part many teams forget: equilibrium doesn’t stay locked in once you find it. Business requirements change, regulations adjust, user behavior evolves, and attackers adapt. What feels finely tuned today can turn obsolete tomorrow if it’s treated like a one-time setup. Which brings us to the closing insight—this balance can’t ever be static; it has to be treated as an ongoing practice.
Conclusion
Security and productivity don’t have to pull against each other. They’re not rivals, they’re partners in the same system. The trick is realizing balance isn’t a static rule you configure once—it’s an ongoing alignment that shifts as your environment shifts. Policies, access, and roles all carry ripple effects you can’t see until users start feeling them.
So here’s your challenge: pick one area of your M365 environment this week and review it through a systems lens. Ask what else it affects beyond the immediate setting. The perfect setup isn’t max security or max freedom—it’s when nobody notices because everything just works.
Share this post