Avoiding security settings that slow people down
Security settings slow people down when they add repeated logins, password resets, approvals, or app blocks without reducing much real risk. In a small company, the fix is usually to keep the strong controls, like MFA and access limits, but use them more selectively with single sign-on, risk-based authentication, tighter app rules, and a faster exception process.
What slowing people down with security settings actually means
Slow security settings are controls that create repeat friction in normal work: users have to stop, re-enter credentials, ask for approval, or hunt for a workaround far more often than the risk justifies. The problem is not any one prompt or policy by itself. The problem is a control that shows up so often that people start ignoring it, resenting it, or finding ways around it.
For example, asking someone to verify their identity again when they open payroll is reasonable. Asking them to do the same thing every time they switch between two low-risk internal tools is usually just noise. The same goes for file sharing, browser rules, and device checks. If the setting does not change based on context, it often treats safe activity and risky activity the same way, which is a poor trade-off.
The real goal is to reduce unnecessary interruption while keeping the right checks in the right places. That usually means fewer prompts for routine work, and tighter checks only where the exposure is higher.
Which settings users complain about first
The complaints usually start with the settings people hit most often during the day. Password rules are a common one, especially when they force frequent changes or demand complicated patterns that are hard to remember. That often leads to written-down passwords, predictable variations, or repeated reset tickets, none of which help much.
Repeated logins and MFA prompts come next. If users are asked to authenticate again and again during the same work session, they feel blocked even when the system is technically doing its job. Access approvals can create the same effect, especially when a manager or IT approval is needed for routine tasks that should already be covered by role-based access.
Overly broad app blocking is another common source of friction. Say a browser extension, sync tool, or file type is blocked everywhere because it is risky in one case. That may protect you in the narrow case, but if it stops accounting, sales, or support from doing normal work, people will look for a workaround.
Typical friction points include:
- Frequent password resets for passwords that are already strong enough
- MFA prompts that repeat too often on trusted devices
- Approval chains for low-risk access requests
- Blocking whole apps instead of the specific risky feature
- Device checks that fail without clear reasons
When a setting is protecting you and when it is just getting in the way
A setting is usually worth keeping when it matches the risk of the action. It is getting in the way when the same control is applied to low-risk and high-risk actions with no distinction. The key test is simple: does the control stop something that would otherwise be hard to recover from, or does it just make ordinary work slower?
For example, enforcing MFA for email, finance systems, admin portals, or remote access to sensitive data makes sense because those systems can expose a lot if an account is taken over. But forcing the same level of interruption for every low-risk action, such as viewing a non-sensitive internal page from a trusted device, may not buy you much.
Another test is what happens after a failure. If the control blocks the action but gives users a clear, fast path to recover, that is usually a sign of a useful control. If it blocks them and nobody can explain why, or if IT has to approve every exception manually, the setting may be stricter than it needs to be.
A good rule of thumb is to ask whether the control changes based on context like device trust, location, system sensitivity, or user role. If it does, it is probably trying to fit the risk. If it does not, it may just feel strict.
Why teams add friction in the first place
Teams rarely add friction because they want to make work harder. They do it because they are trying to reduce account takeover, data leakage, accidental sharing, and unauthorized changes. That matters, especially in a small company where one bad click can affect a lot of systems at once.
Password rules exist because weak or reused passwords are still a common risk. MFA prompts exist because stolen passwords alone should not be enough to get in. App blocks exist because some software is hard to supervise or can move data where it should not go. Approval flows exist because not every user should be able to reach every system.
The trade-off is that the same control can protect against one risk while creating another problem: slower work, more support tickets, or people bypassing the process. A policy that is too strict can push users toward shadow IT, shared accounts, or one-time exceptions that become routine.
So the answer is not to remove friction everywhere. It is to make sure the friction is aimed at the biggest risks, not applied as a blanket habit. When you understand why a rule exists, it becomes easier to decide whether the rule still earns its place.
How to keep protection high without making every task harder
The best replacements for clunky settings usually reduce repetition rather than remove security. Single sign-on is a good example. If users sign in once and can reach the tools they are allowed to use, you cut down on password fatigue and login loops without opening the door wider than necessary.
Risk-based or adaptive authentication is another strong option. Instead of asking for the same level of verification every time, you can tighten the check when the signal looks riskier: a new device, a strange location, an admin action, or access to sensitive data. For low-risk activity on a trusted device, the user gets out of the way faster.
Least-privilege access also helps. If people only have the access they actually need, you can make the controls around that access simpler. The same goes for clear device trust rules. If a device is enrolled and healthy, it should not be treated the same as an unknown laptop from outside the company.
Practical alternatives include:
- Single sign-on for common business apps
- Adaptive MFA for risky logins and admin tasks
- Role-based access instead of ad hoc permission grants
- Device trust policies with clear enrollment rules
- Time-limited exceptions for legitimate edge cases
The other half is better policy exceptions. If users have to fight the policy every time they need a legitimate tool or file action, build a quick review path instead of making them improvise. Make the request easy to find, assign an owner, set an expiry, and keep the review narrow so a one-off need does not turn into a permanent hole.
A practical way to tell the difference between a protective setting and a pointless one is to ask three things: does it block a real path attackers use, does it adapt to context, and can users recover without a long support loop? If the answer to all three is no, the setting is probably only feeling strict.
Where the balance changes by environment
The right level of friction depends on where and how people work. Remote teams usually need stronger identity checks because the network itself is less trustworthy and devices may be outside your control. That does not mean constant prompts, but it does mean better device verification and stronger authentication for sensitive access.
Regulated industries need more structure because the cost of a bad decision is higher. In those environments, some friction is worth keeping if it supports audit trails, separation of duties, or data handling rules. The goal is still to avoid pointless repetition, but the bar for exceptions is higher.
Shared devices, such as kiosks or front-desk systems, are different again. You may want shorter sessions, stronger logout behavior, and tight app access, because the main risk is someone walking up to an already open session. High-risk admin accounts are another special case. Those accounts should face more checks than everyday user accounts, because the damage from misuse is much larger.
This is where a one-size-fits-all policy breaks down. A settings choice that is fine for a standard employee laptop may be the wrong call for a shared tablet or a domain admin account. That is also where a little friction is worth it: if the trade-off protects sensitive systems, auditability, or privileged access, the slowdown can be justified.
A simple way to review your current settings
Start by listing the settings that generate the most complaints or support tickets. Then sort them into two groups: those that reduce real risk, and those that mostly create delay. You do not need a perfect risk model to begin; you need a clear picture of where people are getting stuck.
A practical review can follow these steps:
- Pick the top friction points, such as password resets, repeated MFA prompts, blocked apps, or approval delays.
- Ask what risk each setting is meant to reduce.
- Check whether the setting changes with context, or treats all users and actions the same.
- Identify any workarounds users are already using.
- Test a narrower or smarter version with a small group before changing it for everyone.
When you test a change, watch both the user experience and the security outcome. A faster login flow is a win only if it does not create new exposure.
If you can, compare before and after in plain terms: fewer password resets, fewer blocked legitimate actions, fewer support tickets, and no obvious increase in risky access. You do not need perfect metrics to see whether the policy is working better.
What to change first if people are already working around the rules
If people are bypassing the rules, start with the settings that force the most repeated friction. Login loops are usually the first place to look. If users have to authenticate too often, or they get kicked out of sessions too quickly, they will start storing passwords badly, sharing accounts, or avoiding approved tools.
Next, tighten exceptions instead of making them harder to request. A slow, opaque exception process pushes people toward informal workarounds. A clear path for temporary access, with a reason, an owner, and an expiry, keeps control in place without turning every exception into a project.
Then look at app blocking. If the policy is too broad, narrow it to the actual risky behavior instead of blocking the whole app or file type. That keeps the useful parts available while still controlling the danger.
Finally, review the approval flow. If too many ordinary tasks need manual sign-off, push more of that access into roles, groups, or pre-approved paths. The fastest improvement usually comes from removing friction where the same people are making the same legitimate request over and over.
Conclusion
The best security settings are the ones people can live with because they make sense in context. Start with the controls that create the most complaints, then replace blunt rules with targeted ones that change based on risk, device, or role. That usually means fewer prompts, clearer exceptions, and tighter protection where the damage would actually be serious. If you fix the high-friction settings first, adoption tends to improve before you have to touch the more sensitive controls.
Frequently Asked Questions
Should I reduce password complexity rules if people complain about them?
Not automatically. First check whether the rule is causing resets, predictable passwords, or tickets without much benefit. In many cases, better authentication and password managers help more than making the password rule stricter.
Is MFA always worth the friction?
MFA is usually worth it for sensitive systems, admin access, and remote logins. It is less useful when it is triggered so often that people start ignoring it or looking for workarounds. Adaptive MFA can help keep the balance.
How do I know if app blocking is too broad?
If the block is stopping normal work across a whole team, or users are asking for the same exception over and over, the policy is probably too broad. Narrowing the rule to the risky function is often a better fit.
What is the first change to make if users are bypassing security?
Look for repeated login problems and slow exception handling first. Those are common places where people give up and improvise, which usually hurts both security and productivity.