Security roles in Dynamics 365: why ‘a system administrator’ is a ticking time bomb | Custom IT Brouwer

In many Dynamics 365 environments I look at under the hood, I come across the same situation: a large number of users with the System Administrator role, while that role is meant for a handful of people who actually manage the environment technically. It is one of the quietest, but most real risks in a Dynamics 365 environment.

Security roles are, like connection references and service principals in Power Platform, the kind of topic that feels technical and internal — until the moment it goes wrong. A user accidentally editing records of a department they shouldn’t have access to, a report showing sensitive data to someone who shouldn’t see it, or an audit that reveals nobody quite knows anymore who has which rights, or why.

Why the “System Administrator for everyone” approach happens

The reason is almost always pragmatic, not malicious. During an implementation it’s easier to give everyone broad rights, so nobody gets blocked while the setup is still being finished. After go-live, cleaning up those rights is often postponed — there’s no urgent trigger, the system works, and nobody has time to figure out exactly who needs which role.

What security roles, business units and teams actually do

Dynamics 365 has three interrelated mechanisms for managing access. Security roles determine which actions a user is allowed to perform on which type of record — read, write, delete, assign — and at which level: only their own records, records within the business unit, or all records in the organisation.

Business units: the scope within which a role operates

Business units divide the organisation into departments or units, and thereby determine the scope within which a security role operates. A salesperson with a role that grants access at business unit level only sees records within their own business unit — not those of another department, even if they happen to have access to the system.

Teams: a third, flexible layer

Teams provide a third layer: a way to group rights around a project or temporary collaboration, without affecting a user’s standard business unit structure. Teams are particularly useful when people from different business units need to collaborate temporarily on a specific set of records.

The practical risks of overly broad rights

The most direct risk is data loss or corruption: a user with more rights than needed can, by accident or through ignorance, modify or delete records that fall outside their responsibility.

A third, often underestimated risk is that overly broad rights create a false picture of who is responsible for what. If everyone can do everything, a mistake can no longer be traced back to who made the change based on their role — only who was technically capable of it, which in an environment without role separation is almost everyone.

“If everyone is a System Administrator, no one is accountable. Role separation isn’t just a security measure — it’s also the foundation of traceability.”

How to set up a security model properly

The starting point is least privilege: every user gets exactly the rights needed for their role, no more. In practice, this means drawing up a role matrix: which functions exist within the organisation, which actions logically belong to them, and which scope — own, business unit, organisation-wide — is appropriate for each function.

Restoring an existing, overly broad structure

For organisations already in the situation where too many users have too many rights, a gradual approach is wiser than an abrupt intervention. First, an inventory of who has which role and why. Then, drawing up a new role matrix based on actual job requirements. Followed by a period in which the new roles exist alongside the old ones, so any gaps in the matrix become visible before the old, overly broad roles are revoked.

This approach takes more time than changing all rights at once, but prevents users from suddenly being blocked from work they genuinely need to do — which in practice often does more damage to support for the clean-up than the original overly broad rights ever did.

A revised structure typically has these characteristics:

• A role matrix exists and is maintained — Functions and their corresponding rights are documented, not just stored in someone’s head.
• System Administrator is the exception, not the default — Only those who technically manage the environment hold this role.
• Scope matches the function — Own records, business unit, or organisation-wide, deliberately chosen per role.
• Teams are used for temporary collaboration — Not as a permanent workaround around the business unit structure.
• Changes are traceable — If something goes wrong, it can be traced back to who made the change, based on which role.

When should you bring in help for this?

Restructuring a security model in a live production environment requires precision: a wrong change can block users from work they need to do that very day. This kind of change shouldn’t be made without a clear picture of the impact beforehand.

I help organisations draw up a role matrix, restructure existing, overly broad rights, and set up a model that grows with the organisation instead of having to be reinvented after every expansion.