Protecting privileged access

Accounts that can change everything

At 10:05 on the morning Riley's account was taken over, a caller posing as an IT contractor asked Cedar Inc.'s help desk to reset MFA on an administrator's account. Rowan called back the number in Cedar's directory, found that the administrator had asked for nothing, and refused, as Attacks on recovery and the help desk describes. The attacker already had Riley's mailbox. What they asked for next was an administrator.

An administrator account is worth more than any one person's data because it can change the rules for everyone else. It can reset other people's sign-in methods, create accounts, assign roles, change the sign-in policy, approve applications for the whole organization, add a trusted identity provider and, in some systems, read or switch off the records that would show any of this. Privileged access is access like this, which reaches beyond one person's own work to other accounts, configuration and security controls.

Privilege is broader than the job title "administrator". Help desk staff who can reset other people's sign-in methods hold privileged access, and so do people who own powerful integrations, people who can approve applications for everyone, and the emergency accounts kept for outages. Each needs protection in proportion to what it can change, starting with how much of that access exists at any moment.

Fewer administrators, for less time

An account that holds administrative rights all the time is one stolen session away from an attacker using them. This is standing access: the role is active whether or not its holder is doing administrative work. Most administrators spend most of the week on email, documents and meetings like everyone else, with their administrative role active in the background the whole time.

Just-in-time access turns the role into something an administrator activates when they need it. The account is eligible for the role but does not hold it. To activate it, the administrator gives a reason, signs in again with a strong method and, for the most powerful roles, waits for a second person to approve. The role stays active for a fixed window and then expires on its own. Temporary, privileged, and emergency access follows this process from the request to the review afterward. The table follows one fictional Cedar identity administrator through a week under each model.

Suppose this administrator's session is stolen on Tuesday afternoon. With standing access, the attacker holds every administrative permission as soon as they replay it. With just-in-time access, they hold an ordinary account, and activating the role needs a fresh strong sign-in they cannot complete and an approval someone else has to give. Activation requests are visible too. One made at an odd hour, for an unusual role or with a vague reason is easy to question.

Fewer administrators matter as much as fewer hours. Roles scoped to one task, such as resetting methods for ordinary employees or managing one application, mean that most administrative work never needs the most powerful roles at all, and the handful of people who hold those roles are easier to protect and to watch.

Stronger sign-in for stronger access

An administrator who reads email with the same account they use to run the organization brings every phishing message and malicious link to the account with the most power. A separate administrative account, used only for administration, keeps that power off the everyday account, which faces the most attacks. Because the administrative account never reads mail or browses the web, a phishing message has far fewer ways to reach it.

Riley's takeover shows why the sign-in method matters. Riley's password and authenticator-app code passed straight through a relay page, and the attacker kept the session Cedar's real identity provider issued. A passkey or security key would have failed at the relay, because the browser ties the credential to the real site's address, as Phishing and relayed sign-ins explains. Administrative accounts are where phishing-resistant methods should start, set through the kind of policy described in Authentication policy and SSO.

Freshness matters as well, but a recent sign-in check cannot stop a stolen session that is itself recent, as Limiting what stolen access can do explains. For privileged actions, the service should ask for a phishing-resistant method at the moment of the action. Administrative sessions can also be shorter and limited to managed devices, so that a copied session is useful for less time and from fewer places.

Recovery has to match. An administrator whose MFA can be reset after a convincing phone call is only as well protected as that call. Resets for privileged accounts need more than an ordinary reset: a callback to a number already on record, a second person's confirmation, or proofing the person again, as Attacks on recovery and the help desk describes.

Emergency access

Strong protections can also lock out the people they protect. If the identity provider's MFA service has an outage, a new sign-in policy is misconfigured, or the administrators cannot reach their security keys, someone still needs to get in and fix it. Emergency access accounts, often called break-glass accounts, exist for that moment.

Because they must work when other things have failed, emergency accounts are often exempt from rules that ordinary administrators follow, such as depending on single sign-on. That makes them valuable to an attacker, so they are protected differently. There are very few of them. Their credentials, long random passwords or security keys, are kept in separate secure places, and access to those places is itself controlled and recorded. They are never used for everyday work, so any sign-in is either an emergency someone already knows about or a sign that something is wrong. Every sign-in should alert several people, and the credentials are replaced after each use, including each test.

An emergency account also has to work on the day it is needed. Credentials get misplaced, the PIN for a stored security key is forgotten, a policy change quietly starts applying to the account, or the person who knew the procedure leaves. Testing it on a schedule, by signing in, confirming that the alert fires, checking that the account still has the access it needs and then replacing its credentials, replaces an assumption with something known.

Never losing the last administrator

An organization can lose control of itself without any attacker. If the only administrator who can manage roles removes their own role, or leaves and has their account disabled, nobody remains who can assign that role again. The system should refuse any change that would leave no one with authority to manage roles: removing the last such assignment, disabling the last such account, or deleting the role itself.

The check also has to hold when two administrators remove each other's roles at the same moment. Each request would see the other administrator still in place, so the service has to make the check and the change one step, as Administering roles safely explains.

An attacker who gains administrative access may try something similar on purpose, removing the other administrators so that defenders cannot undo their changes. The last-administrator rule alone does not stop that, because one administrator, the attacker, remains. Alerts on administrator removals, approval before privileged roles are removed, and emergency accounts that sit outside ordinary role management give defenders a way back. Each refused removal is recorded with its reason.

Watching what administrators do

Privileged actions are rare compared with ordinary activity, which makes them worth recording in full and watching closely. Each record needs the administrator who acted, the account or setting affected, what changed from and to, the outcome, and a request ID that connects it to related events. Recording identity activity covers what makes records like these useful.

Some changes deserve an alert the moment they happen: a new administrator assignment, a change to the sign-in policy, a new trusted identity provider, an emergency account sign-in, and a help desk reset of an administrator's methods. Refused requests matter as well: a refused MFA reset for an administrator's account tells an investigator that someone was reaching for more than the account they already had.

Administrators should not be able to edit or erase the records of their own actions, and the people who review those records should not be the people being reviewed. Elevation requests, approvals and activations from just-in-time access belong in the same history, so a reviewer can see who held which role, when, and for what stated reason.