Account administration: common questions and clear answers

Administration is the part of a business platform that nobody evaluates during a trial and everybody lives with afterwards. The features get demoed. The admin console gets a five-minute tour. Then one person inherits it, and three years of small decisions harden into the thing that is too painful to change.

This page answers the questions that come up in that order: the ones people ask on day one, the ones they ask after the first incident, and the ones they wish they had asked before the team doubled.

What to take away

• Five decisions taken before the first account exists will shape everything afterwards: separate administrative accounts, a break-glass account, the naming convention, logging, and who may connect outside applications.
• Attach access to groups, never to names. Access granted to a person is access nobody can review.
• The process that matters is the leaver, not the joiner. Adding access is somebody's job and removing it is nobody's.
• Log retention usually starts when logging is switched on, so the cheapest thing you will ever do here is enable it today.

What should I set up before the first user logs in?

There is a short list of decisions that are cheap now and expensive later, because everything else gets built on top of them.

Give administration its own accounts. The person who administers the platform should have a normal working account and a separate administrative one. Day-to-day mail and browsing happen in the first; the second is used only to change settings. This single split limits the blast radius of a compromised session or a bad link, and it makes the audit log meaningful: every administrative action is attributable to a deliberate act rather than to someone's ordinary Tuesday.

Create a break-glass account and then leave it alone. One account that is not tied to any individual, not enrolled in the same second factor as everyone else, and not dependent on any single person's phone. Its credentials go somewhere physical and controlled. Test that it works, on a schedule, and record the test. Organizations lose access to their own tenant more often through a departed administrator or a lost device than through any attack.

Decide the naming convention now. Address format, display-name format, what happens with duplicates, what happens with contractors. You will not change it later without breaking things that reference the old form.

Turn on logging before you need it. Audit logs usually have a retention period, and the period frequently starts when logging is enabled, not when the account was created. Investigating an incident and discovering that the relevant window has already aged out is a common and entirely avoidable failure. Decide the period against what you might be asked rather than against what is tidy, which is the practical argument in the guidance on logging and monitoring.

Decide who can install and connect third-party applications. By default, many platforms let any user grant an external application access to their data. That is a genuine convenience and a genuine risk, and the default is a decision you are making whether or not you look at it.

Should permissions go to people or to groups?

Groups. Always groups, even when the group has one member.

Assigning access directly to individuals feels faster and produces a system nobody can audit. Six months in, the only way to answer "who can see this?" is to open each item and read a list of names. And when someone leaves, their access is scattered across hundreds of individual grants rather than removed by taking them out of two groups.

Build groups around function, not around the current org chart. "Whoever handles supplier invoices" survives a reorganization. "The finance team as of last March" does not.

The practical test: can you describe every person's access by naming the groups they belong to? If you cannot, you have exceptions, and exceptions are what leak.

What does a good joiner, mover, leaver process look like?

Most administration pain is really lifecycle pain. Three events, and only one of them is usually handled well.

Joiner is the easy one, because someone is waiting and complaining. The thing to get right is that new access comes from a defined role, not from copying an existing person's account. Copying is how one over-privileged account quietly becomes twenty.

Mover is the one that is almost universally broken. When someone changes role, their new access is added and their old access is never removed. After a few internal moves, long-tenured people accumulate access to everything they have ever touched. Nobody notices, because nothing is ever denied. Treat a role change as a leave and a join: remove first, then add.

Leaver is the one with legal and practical consequences. Before you delete anything, work out:

• Who inherits the person's files, and whether inheritance preserves or breaks existing shares.
• What happens to mail sent to their address afterwards: silently bounced, forwarded, or delivered to a monitored shared mailbox. Each has different implications, and forwarding to a colleague's personal mailbox is the one that causes trouble.
• Which automated processes were running under their account. This is where a departure quietly breaks an integration weeks later.
• Whether their account is the sole owner of anything: a group, a shared document, a connected application.
• What your retention or legal obligations require you to keep, and for how long.

Deleting the account is usually the last step, not the first. Suspending it (access revoked, data intact), buys time to answer all of the above.

How much administrative power should administrators have?

Less than the platform offers by default, and different amounts for different jobs.

Most platforms distinguish between full administrative control and narrower roles: someone who can reset passwords but not change security policy, someone who can read audit logs but not alter them, someone who manages billing but not data. Use them. The person who does daily user administration does not need the ability to change your authentication configuration.

Two rules that hold regardless of platform:

• The number of full administrators should be small enough to name from memory, and larger than one. One is a single point of failure; five is a governance problem.
• Nobody should be able to remove the evidence of their own actions. If your administrative role can also purge the audit log, your audit log is a comfort object.

Review the administrator list on a schedule. Elevated access granted "temporarily" for a project is never revoked by anyone except a scheduled review.

What is the third-party application problem?

When a user connects an external tool to your platform, they grant it access on their own behalf: often to their mail, files, or calendar, sometimes to the whole organization's. The connection outlives their interest in the tool. It frequently outlives their employment.

Three things to establish:

• A visible inventory of which applications hold access, with what scope, granted by whom. If you cannot produce this list, you do not know what has your data.
• A rule for who may grant access. Either users may connect anything, or they may connect from an approved list, or an administrator approves each request. All three are defensible. Not choosing means you have chosen the first one.
• A revocation path you have actually used. Removing an application's access is not the same as deleting the application, and neither necessarily deletes the copy of your data it has already taken.

Pay attention to scope rather than to the vendor's reputation. An application that asks to read all mail in the organization is a different risk from one that asks to read a single calendar, no matter who makes it.

What should be tested, not assumed?

Administration is full of settings that look configured and are not functional. Test these:

• Recovery. Restore something. Not a demonstration in a sandbox: restore an item that a real person deleted, using the process a real administrator would follow, and time it. Discover the retention window's actual length by using it, and find out whether recovery restores permissions along with content.
• The second factor's failure mode. What happens when someone's phone is lost, broken, or in another country. If the answer is "an administrator resets it", make sure administrators can verify identity by some means other than the email address that is currently locked.
• Offboarding, end to end. Run it on a test account with files, calendar entries, group memberships, shares, and a connected application. Note everything that survives.
• Alerting. Trigger a condition that should produce an alert and confirm someone receives it. Administrative alerts routing to a mailbox nobody reads is the norm, not the exception.

Which admin controls do people wish they had set up first?

Asked after the fact, the answers are consistent:

Control	Why it matters later
Separate administrative accounts	Makes the audit log attributable and limits what a compromised working session can reach
A tested break-glass account	The difference between an inconvenience and losing control of your own platform
Groups for every grant	The only way to answer "who has access to this" without opening every item
Logging enabled from the start	Retention windows begin when logging begins, not when the incident happens
A rule for third-party app consent	Determines whether your data inventory is knowable at all
An external-sharing default	Once "anyone with the link" is habitual, it is very hard to withdraw
Named ownership of shared resources	Prevents orphaned groups, mailboxes, and folders when people leave
A documented offboarding sequence	Turns a departure from an improvised scramble into a checklist
Scheduled review of elevated access	Nothing else removes temporary permissions

None of these depend on which platform you chose. All of them are harder to introduce once there are people and content in the system.

How does this change as the organization grows?

The transitions are more abrupt than people expect.

Below the point where anyone specializes, administration is one person's side responsibility. The main risk is bus factor: one person knows everything and has documented none of it. The mitigation is not more process, it is a written record of decisions and a second person who can get in.

At the point where teams stop knowing each other, informal access control fails. You cannot rely on "ask before you share" once people cannot name everyone. This is the moment groups, defaults, and a sharing policy stop being bureaucracy and start being the only thing that works.

At the point where you have compliance obligations, retention, audit, and evidence become the constraints. This is when the decision to enable logging on day one either saves you or costs you.

The mistake is administering as though you are still at the previous stage. The mistake in the other direction, building a large organization's governance for a team of eight, is real, but it is far cheaper to fix.

What to ask a vendor about administration

During an evaluation, the admin console gets less scrutiny than it deserves. Ask:

• Which administrative roles exist below full control, and what exactly each can and cannot do.
• How long audit logs are retained, whether that is configurable, and whether logs can be exported.
• What the deletion and recovery windows are, and whether recovery restores permissions and sharing state.
• Whether the offboarding process preserves shares that other people depend on.
• Whether single sign-on, provisioning from your identity system, and detailed audit logging are included, or sit in a higher tier. They frequently sit higher, and finding out after you have committed is an expensive surprise.
• What administrators cannot do: the operations that require contacting support, and how long that takes.

That last question is the most revealing one. Every platform has a set of actions reserved to the vendor. Knowing which ones, before you depend on the platform, tells you where your control actually ends.

The published secure configuration baselines for cloud business applications are a reasonable starting point for deciding which of those settings you should be enforcing, independent of whose product you are running.

Where to read next

This layer sits underneath everything else on the estate, so its consequences show up elsewhere. The mail decision is where a missed leaver hurts first, and the hosting arrangement determines who holds the keys to the domain. The storage decision is where orphaned content accumulates, and the suite decision usually determines which directory you already own.

Common questions

How many administrators should a small organization have?

At least two, so that one person's absence is not an outage, and no more than the number of people who genuinely need to change settings. The number worth watching is how many hold the highest level of rights, which should be small, named, and reviewed twice a year.

Where should the break-glass credentials actually live?

Somewhere physical and controlled, such as a safe, with a written note of who may open it and under what circumstances. The point is that it does not depend on the platform you would be locked out of, or on any single person's device.

Do we need to review access if nothing has changed?

Yes, because things change without anyone deciding they have. Projects end, contractors finish, and people move teams without a formal move. A review that removes nothing is usually a review that was not really done.

What do we do about the application somebody connected two years ago?

Find out what it can reach and who owns it. If nobody can name an owner or a purpose, revoke it and see who complains. That is a blunt method and it is faster than any investigation, provided you do it on a Tuesday rather than a Friday.