Most MSPs treat Autotask security levels as a one-time setup task. You configure them during onboarding, maybe copy a system default or two, assign them to users, and move on. Then six months later your technicians are hitting permission walls mid-ticket, your dispatchers can't reassign work without calling someone, and your managers are asking why they can't see the data they need. You chalk it up to "PSA weirdness" and keep moving.
The problem isn't Autotask. The problem is that your security level configuration is either accelerating your help desk or quietly strangling it, and most MSP owners never stop to figure out which one.
Here's what that actually costs you, and how to fix it.
A technician picks up a ticket. They diagnose the issue, document their work, and go to close it. Permission denied. Now they're Slacking a manager, waiting for someone with the right access to click a button, and the ticket sits in limbo. Multiply that by twenty tickets a day across six technicians and you've built an invisible tax into every workflow your help desk runs.
The insidious part is that this never shows up cleanly in KPI reporting. Your ticket closure time looks slow, but the dashboard doesn't say "technician was blocked by a permission wall for 40 minutes." It just says the ticket took longer than it should have.
Common symptoms of poorly scoped security levels:
Each of these is a workflow bottleneck with a permission problem at its root. The fix isn't to hand out admin rights. That leads somewhere worse.
When permission walls keep appearing, the path of least resistance is to bump someone's access level. One admin-level permission here, Full Access there, and suddenly half your team has more access than they need. I've seen MSPs where every technician has essentially unrestricted access because somebody got tired of fielding "can you do this for me" requests.
Autotask's own documentation is explicit about this: the Full Access security level "was designed as a backup to your Autotask Administrator security level" and Autotask recommends you do not assign it to resources. It exists as a break-glass option, not a default for senior techs.
Admin creep creates three real problems:
The fix is role-based access built on least-privilege. Which means you need a deliberate structure, not just "technician" and "admin."
Autotask ships with system security levels designed around typical MSP roles. The right approach isn't to use them as-is. It's to use them as templates, copy them, and customize the copies to match your actual job functions. Per Autotask's security level guidance, this is the documented best practice, and it also makes onboarding new staff straightforward since you just assign the right custom level.
Here's a practical structure for most MSPs:
Two additional things belong in this conversation. First, inactivate system security levels and custom levels you're not using. If they're available, someone will eventually assign them, and you'll have inconsistency you didn't plan for. Second, set up security event notification recipients so you get alerted when permission-related changes happen. Both are documented in Autotask's security best practices guide.
On 2FA: it's mandatory in Autotask for all non-API license types unless you're running SSO. This isn't optional configuration anymore. What is worth reviewing is whether you've paused 2FA requirements for specific users who "had issues" and never re-enabled it. Check your resource records under the Security tab and clean that up.
This one gets skipped constantly. If you've connected RMM integrations, billing platforms, or documentation tools to Autotask via API, and they're all running under one shared API user account with broad access, you have a problem that security auditors will find even if you don't.
The correct approach is one API user per integration, each with a security level scoped to only what that integration needs. An RMM sync doesn't need access to your financial data. A documentation tool doesn't need to create resources or modify security settings.
Autotask provides both an API User (system) and an API User (system) Can't Read Costs (API-only) security level specifically to support this. If an integration only needs read access to certain entities, scope it that way. If it only needs to create and update tickets, scope it that way.
This matters for more than security. When an integration starts behaving strangely, knowing exactly what it can and can't access makes troubleshooting significantly faster. "Our billing integration is touching ticket workflow rules" is a diagnosis you can only make if the security levels told it what it was and wasn't allowed to do.
A well-structured security level configuration doesn't just reduce risk. It directly improves help desk throughput in ways you can actually measure.
When technicians have exactly the access they need to work their tickets from open to close, escalation confusion drops. There's no "can you close this for me" or "I need someone with access to reassign this." The ticket moves because the person working it can move it.
Clean data boundaries also make workflow automation more reliable. Autotask automation rules, SLA workflows, and ticket routing logic all depend on consistent data. When technicians are working in scoped environments, they're less likely to accidentally edit fields or categories that trigger the wrong automation. Your workflows do what you configured them to do instead of misfiring because someone with too much access touched something they shouldn't have.
Finally, reporting accuracy improves. When access is scoped, data changes come from expected sources. Auditing who did what becomes meaningful. Manager dashboards reflect reality instead of a mix of intentional actions and accidental edits.
If you've never done a security level audit, here's a practical starting point:
After each Autotask release, check the release notes and update your custom security levels to account for new features. System security levels get updated automatically. Yours don't.
Permission structure is infrastructure. You wouldn't leave your network firewall rules in place from three years ago without reviewing them. Your Autotask security levels deserve the same attention.
Clean permissions remove friction. Automation removes the rest. With security levels scoped correctly, Rocketship automatically triages, dispatches, and schedules tickets in Autotask based on skills and availability, so technicians and dispatchers stop waiting on someone else to reassign or move work forward. Need a hand? Our Autotask Consulting team can help, or grab the free Autotask Data Clean-Up Kit. You can also schedule a demo of Rocketship.