I opened Access Control on a client’s production tenant recently and found fourteen people with SUPER. Four of them no longer work there. Two are consultants from a partner that was replaced in 2023.
Nobody decided that. No meeting included weighing the risk and signing off. During go-live, someone needed full access to fix something at 11 pm; SUPER got assigned, the project closed, and the assignment stayed exactly where it was. Three years later, it is still sitting there.
That isn’t one security failure. It’s fourteen small decisions nobody ever revisited.
The argument people want to have
When I point this out, the reflex is to argue about who is entitled to access. Whether the partner should have it. Whether the controller needs it. That’s the wrong argument.
Your implementation partner probably does need SUPER sometimes. Something breaks at month-end, and the alternative is a three-day ticket. I’m not going to pretend otherwise, and I’d rather they had it than watch a client sit on a broken posting run for a week.
The problem isn’t that they have it. It’s that they have it on a random Tuesday in March when nobody has asked them for anything.
Business Central doesn’t help here.
You assign a permission set, and it stays assigned until someone remembers to take it off. The record has no expiry date. There is no “until Friday.”
Look at what you can actually narrow. An assignment is scoped to a user and to a company. That is the whole list. You can control who, and you can control where. You cannot control when. And in plenty of tenants, the assignment isn’t narrowed at all; it sits open across the entire thing.
So the question was never who should have SUPER. It’s what should happen to SUPER at 6 pm.
What we built.
For a client running Business Central in production, the answer works like this. You request elevated access. You get it for a fixed window. It’s removed automatically when the window closes.
No form. No approver. No ticket sitting in someone’s queue while the month-end problem gets worse.
Read-only is the resting state, the place everyone returns to. Elevated is somewhere you visit for an hour.
Nobody has to remember anything, and that matters more than it sounds. Every permissions process I’ve seen that depends on someone remembering has already failed. It just hasn’t been audited yet.
Revocation is the hard part.
Granting access is easy. Anyone can build the granting.
People are extremely reliable at requesting access and completely useless at handing it back. So the design effort goes into removal, and in our case it gets three independent nets.
- A scheduled task created at the moment of the grant, set to fire at the expiry. The manager codeunit’s OnRun revokes it. Nothing else needs to be awake for it to happen.
- A sweep every time the dashboard opens, catching anything already past its expiry. It’s cheap, and it means the page can never sit there showing you a grant that should have died an hour ago.
- A job queue janitor, for the week when nobody opens the page at all.
Belt, braces, and a second belt.
One detail about how it runs, because it surprised the client. The grant and the revoke happen under escalated permissions through an Entra app, not in the context of the person clicking the button. It has to work that way. In BC, assigning someone a permission set requires you to hold at least that level of permission yourself, so a flow running as the requesting user would only ever work for people who already had what they were asking for.
Then build the part that tells you it’s broken.
A revoke path that fails silently is worse than having no control at all. Not because the access is any more dangerous, but because you will believe it’s gone.
So every grant row carries its revoke attempt count, the last error, and whether a task is genuinely scheduled. When revocation breaks, the dashboard says so, loudly, instead of quietly leaving somebody with SUPER and a green tick.
Build the control. Then build the part that tells you the control is broken.
What this doesn’t fix?
Worth saying plainly, because someone will ask. If a person holds SUPER, they can edit almost anything in the database, including the record of who held SUPER. That is true of any in-database log, ours included.
The risk doesn’t disappear. Someone always needs that level of access eventually, and the moment they have it, you are trusting them. What changes is how long the window stays open. Permanent becomes an hour, and something writes down what happened during it.
If your threat model is a hostile insider carefully covering their tracks, you need tooling that lives outside Business Central. If it’s the ordinary case, which is knowing what happened and being able to show someone, this does the job.
The part worth doing today
A time-boxed permission you have to remember to remove is just a permission.
Access Control takes about thirty seconds to open. Count the rows with SUPER, then count how many of those people asked you for it this quarter. Most teams are surprised by the gap, and the ones who aren’t surprised usually haven’t looked recently.
If the number bothers you, get in touch, and we’ll go through what’s actually in there.
