Privileged access is where the blast radius lives. A phished sales account is an incident; a phished super admin is the whole tenant. This is also the area where an interviewer can tell within two answers whether somebody has run a real environment or a small one.
How many super admins
As few as can cover the on-call rota, which in most organisations is a handful rather than a dozen. Everyone else gets a delegated role scoped to what they actually do: the service desk needs password reset and user read, not Drive access or the ability to change security settings.
A custom role can also be scoped when you assign it, so the holder administers one organisational unit rather than the whole domain. That is how a regional lead manages their own people and nobody else's. There is a constraint worth knowing before you design around it: only privileges that mean something per organisational unit can be scoped that way, broadly the user and Chrome management ones. Put a domain-level privilege into the same role, a security or service setting, and the assignment is domain-wide regardless. A role that mixes the two quietly stops being the contained thing you drew on the whiteboard, which is the argument for keeping custom roles narrow rather than convenient.
The number matters less than the honesty of it. Admin rights accumulate the same way any other access does, quietly and with good intentions, so the list needs reviewing on a schedule with a named approver. Treat it as an access certification and remove what nobody will defend.
Separate admin accounts
An administrator's daily account is the one that reads mail, clicks links and joins external meetings. It is the account most likely to be phished. If it also holds super admin, then one bad click is a tenant compromise rather than a mailbox compromise.
So: a separate admin identity, used only for admin work, with stronger requirements than a normal account. Security keys rather than a code. Tighter conditional access. And a shorter session, which is a real setting rather than a wish: session control lives under Security, access and data control, and it takes an organisational unit, so the admin unit can be set to hours while everyone else keeps a working day. That is the practical reason for admins to sit in their own organisational unit in the first place.
It is mildly inconvenient every day and decisive once.
The break-glass account
The uncomfortable question is what happens when your own controls fail. If security keys are mandatory and the keys are lost, if a Context-Aware Access rule is misconfigured and denies every admin, if the sole super admin leaves suddenly, you are locked out of your own tenant and the only route back is a vendor support case measured in days.
Not tied to a person. A named account for the purpose, not somebody's second login.
Excluded from the conditional rules that could deny it. Configure this before the first rule goes live, because afterwards you cannot get in to do it.
Credentials long, random, and split. Two custodians holding halves, or sealed in a safe with a documented procedure for opening it. The point is that no single person can use it alone and unobserved.
Its hardware keys stored physically, not carried in somebody's bag.
Every sign-in raises an alert to people who will notice, because legitimate use is rare enough that any use is worth a question.
Tested on a schedule. An untested recovery path is not a recovery path. Rotate the credentials after each test and after any custodian leaves.
The other privileged credential nobody counts
A service account with domain-wide delegation can impersonate users across whatever scopes it has been granted. That is effectively a second super admin with no face and no session, and it is usually created once for an integration and then never reviewed.
Grant the narrowest scope set that works, keep the key material out of repositories, rotate it, log its use separately from the actions it performs, and put it on the same review cycle as human admin rights. When asked to name the most dangerous credential in a Workspace tenant, this is a better answer than "the super admin password".
Where it goes wrong
Break-glass created after the rules. The one failure that has no recovery except a support ticket.
Admin rights granted for a project and never removed. Put an expiry on temporary elevation at the moment you grant it.
Delegated roles that are super admin in disguise. Read the permissions in a custom role rather than trusting its name.
Service accounts excluded from review because they are not people. They hold more access than most people do.
The short version
Few super admins, delegated roles for everyone else, separate admin identities with stronger authentication, and a break-glass account that is exempt from your own conditional rules, split between custodians, alerting on use and tested regularly. Then remember that a delegated service account is privileged access too, and review it like one.