22 April 2025

SUPER, the dreaded permission set in Dynamics 365 Business Central

The SUPER permission set gives a Business Central user access to every object their license covers, so a SUPER user can change vendor bank details, post purchase invoices and create payment proposals on their own. You reduce that risk by keeping SUPER to the few accounts that truly need it and giving everyone else, including the people who manage users, role-based permission sets instead.

That sounds obvious, yet in many environments SUPER is still the default answer to “I can’t do X”. Here is why that is a problem and how to get out of it.

The SUPER permission set gives a Business Central user access to every object their license covers, so a SUPER user can change vendor bank details, post purchase invoices and create payment proposals on their own. You reduce that risk by keeping SUPER to the few accounts that truly need it and giving everyone else, including the people who manage users, role-based permission sets instead.

That sounds obvious, yet in many environments SUPER is still the default answer to “I can’t do X”. Here is why that is a problem and how to get out of it.

What SUPER actually does

Microsoft describes SUPER as the permission set you assign when you do not want to restrict a user beyond what the license already allows. It opens up all objects specified in the license. The license still sets the ceiling: a user with an Essentials license and SUPER can reach more than a Team Member with SUPER. But within that ceiling, nothing stops them.

For segregation of duties, that is the worst case. One person can create a vendor, change the bank account, enter an invoice, post it and pay it. No conflict analysis will ever come back clean for that user, and an auditor will ask about every SUPER account you have.

Why SUPER spreads

SUPER usually spreads for practical reasons, not bad intentions:

  • User administration. Creating users, assigning permission sets and running the Update Users from Microsoft 365 guide traditionally sits with SUPER users, so IT and key users get it “temporarily”.
  • Troubleshooting. When a user hits a permission error, adding SUPER makes the error go away. Nobody removes it afterwards.
  • Go-live pressure. During implementation, partners and key users work with SUPER to move fast, and the setting survives into production.

Microsoft also requires at least one SUPER user in an environment. So the goal is not zero SUPER users. The goal is a short, known list of SUPER accounts with a clear reason for each one.

Manage users without handing out SUPER

The Authorization Box, 2-Controlware’s web-based application for managing Business Central permissions, moves day-to-day user and permission administration out of Business Central. Changes you make in the Authorization Box sync directly to your Business Central databases.

The Authorization Box talks to Business Central through a dedicated connection user. According to the 2-Controlware wiki, that connection user needs the SUPER permission set, because it is the account that assigns rights in Business Central. The administrators, controllers and managers who work in the Authorization Box do not need SUPER in Business Central themselves. They only get the permission sets that match their own job.

That shifts the risk from many people to one service account. Treat it like any other privileged credential:

  • Use it only for the Authorization Box connection, never for interactive work.
  • Keep its credentials with IT, not with a key user.
  • Review it in every access review, like any other SUPER account.

Organization roles instead of loose permission sets

In the Authorization Box you group permission sets into organization roles, for example “Accounts payable clerk”. Each role is linked to a department in your organization chart and holds every permission set, or permission set group, that the job needs. You can also link a profile to the role.

Instead of assigning ten permission sets by hand, you assign one role. When the role changes, every user with that role follows once the role is processed. This keeps permissions consistent and makes it much easier to explain to an auditor why someone has access.

Requests and approvals when people join, move or leave

Access changes go through authorization requests. A request names the user, the organization roles to assign or revoke, the company or company group, and optional start and end dates. That last part is useful for temporary access, such as a controller covering for a colleague during the year-end close.

If approval is required, the request waits for the approvers you set up, for example a controller or department manager. Approvers can approve or reject, and a rejection needs a memo that stays visible in the processed records. You can set the number of approvers globally, per approval group or per organization role.

Find the SUPER users you already have

Before you clean up, you need a list. In Authorization Monitoring, SUPER is a textbook example of a permission set that always results in a risk finding, because it lets a user change all data. You can review those findings per user or per organization role and mark them as agreed or disagreed, which gives you a documented decision for every remaining SUPER account.

Microsoft has also improved native visibility. The Permissions Overview page (public preview in BC28, March 2026) shows permission sets, security groups and assignments across apps, and since BC28.2 (GA 14 June 2026) five read-only permission analysis APIs are available for auditors and IT staff. Both are useful for reporting. Neither provisions access nor enforces an approval flow, so they do not remove the reason people ask for SUPER in the first place.

Also check your security groups. Security groups replaced user groups from 2023 release wave 1 (version 22), and user groups stopped being supported after 2024 release wave 2 (version 25). If a security group carries SUPER, every member inherits it, which is easy to miss in a user-by-user review.

A practical clean-up plan

  1. List every SUPER assignment, direct and through security groups.
  2. For each account, write down why it has SUPER. “Convenience” is not a reason.
  3. Move user administration to the Authorization Box and its connection user.
  4. Replace SUPER on the remaining users with organization roles that fit their job.
  5. Keep a short list of break-glass and service accounts, and review it every quarter.

Conclusion

SUPER is not evil, it is just far too powerful for daily work. Keep it on the handful of accounts that need it, protect the Authorization Box connection user like the privileged account it is, and give everyone else a role that matches their job. That is how you stay in control without slowing your organization down.

Frequently asked questions: