The most powerful role is invisible to your SoD engine

The System Administrator role carries zero rows in the privilege model most security analyses are built from. So the accounts with unrestricted access score as the cleanest in the building, and a conflict test built on that model passes by finding nobody.

Across five client snapshots, the System Administrator role produced exactly zero rows in the privilege disposition table. Not a low count. Zero. The role that can do anything appears in the data as a role that can do nothing.

Why the most powerful role has no rows

Security analysis is built on a privilege graph: role to duty to privilege to entry point, with grant and deny verbs on each entry point. Every conflict rule, every least-privilege test, and every license calculation reads that graph. It is a complete picture of access that flows through named privileges.

System Administrator does not grant access through that graph. It grants unrestricted access at a level above individual privileges, so there are no privilege rows to enumerate. When the analysis joins the role to its privileges, it finds none, and the role falls out of every downstream count. The data is not wrong. It is describing the wrong layer, and the one role whose access lives above that layer vanishes.

The test that passes by finding nothing

Run a Segregation of Duties check against that privilege model and the result is quietly inverted. A conflict is two incompatible capabilities in one person's access. System administrators have every capability, so they have every conflict that exists. But the engine reads their privilege rows, finds none, counts zero conflicts, and reports them as clean.

The people with the most dangerous access look like the safest accounts on the report. An auditor scanning for the worst offenders sees the administrators sitting at zero and moves on. Worse, if the administrator population is small and the rest of the estate happens to be quiet, the whole test can return almost nothing and read as a pass. It passed because it was blind to the one group that matters most, not because the estate is clean.

The same trap appears a second time in licensing. "Holds business access today" also has to be read from raw assignments, not from the disposition, for the same reason: the disposition cannot see access that lives outside the privilege graph.

Read administrators from the raw assignments

The fix is to stop asking the privilege model who the administrators are and ask the role assignment table instead. Read the System Administrator population from the raw user-to-role assignments, matching the role by its exact name, and carry those accounts into every report as a distinct category.

On the five snapshots, reading assignments directly returned 55, 46, 49, and 46 administrators on four of the clients, exactly matching what the assignment-scoped view already saw. The privilege disposition returned zero on all of them. One number is the truth and one is an artifact of where you looked.

Match the role name exactly. A substring match such as "contains SYSTEM ADMINISTRATOR" will sweep in every role whose name merely includes that text and mislabel its holders, which in licensing wrongly zeroed out seats and in SoD would hide or invent administrators. Exact name only.

Report them as unrestricted, never as a clean zero

Once you have the real population, give it its own line and label it for what it is: "unrestricted access, every risk applies by definition." Never show an administrator at zero conflicts, and never fold them into the pair counts, because one account with every conflict would swamp the totals and drown the findings that are actually actionable. They are a stated exposure, listed and counted as people, sitting outside the conflict arithmetic.

It helps to tag each account on that list with a class: a person, a service account, a partner or Microsoft account, a generic or technical account. The classification is a heuristic and should be labeled as one, but it lets a reader see at a glance whether the unrestricted population is twenty named humans or a pile of integration accounts, which are very different findings. A related warning sign worth surfacing: a service account that also holds a large stack of business roles is both unrestricted and heavily entitled, which is the opposite of what a service account should be.

While you are reading raw assignments, apply the same honesty to any assigned role that has no security rows at all. That is not a clean role either. It is a role the analysis cannot assess, and it should be listed as not assessable rather than silently scored as safe.

Bottom line

A security test that is built on the privilege graph cannot see the roles that grant access above the privilege graph, and System Administrator is exactly such a role. If your SoD or least-privilege report shows administrators at zero, it is not telling you they are clean. It is telling you it never looked at them. Read the administrator population from raw role assignments, report it as unrestricted with every risk applying, and treat any role with no security rows as unassessed, not safe. A test that passes by finding nothing has not passed.

Frequently asked questions