Privileged access

Privileged Access governs how people get at the most sensitive stored credentials: rather than holding standing access, someone requests it, an approver grants it, and the grant is recorded.

Find it in the header, not the menu

Privileged Access has no menu item. It is reached from an icon in the top-right header bar, alongside the notifications bell.

When there are requests waiting, the icon carries a count badge — so pending approvals are visible from any page rather than only when you go looking. That badge is the intended prompt for approvers.

The icon appears only once privileged access data exists for the account, so an account that has never used the feature will not show it at all.

The same destination is also linked from the Documentation widget on Account Home.

Turning it on

Privileged access is enabled on the Hosted Organizations provider settings, under Settings, not per customer. Enabling it reveals two further settings: the domain name privileged accounts are created against, and the shadow groups the mechanism uses.

It is a platform-level switch

Because it is a provider setting, enabling privileged access affects the organizations that provider serves rather than one customer. Plan it as a platform change.

The three screens

Screen	Purpose
Privileged Access	The entry point — what is protected and the current state of access
PAM Access History	The record of who requested access, when, and what was decided
Privileged Access Request Review	Where an approver acts on a pending request

Why use it

Standing access to a domain administrator password is the thing an attacker wants and the thing an auditor asks about. Privileged access replaces it with access that is requested, approved, time-boxed and logged.

The practical benefit is the history: after an incident, “who could have used this credential, and did they?” is answerable from a screen rather than by inference.

It only protects credentials you put behind it

A credential stored without requiring authorization is available to anyone with access to the password list, and Privileged Access has no view of it. The control is only as good as the decision about which credentials need it — see Requires Authorization on the password entry itself.

Approving a request

An approver sees the pending request in the review screen and grants or refuses it.

An approval is a decision, not a formality

The whole mechanism depends on someone actually considering whether the request is warranted. Approving by reflex reproduces standing access with more steps and a misleading audit trail — one that says access was reviewed when it was not.

Where requests are routinely approved without thought, the credential probably should not be behind privileged access, or the requester should have their own.

Access history

Every request and decision is recorded. Review it periodically rather than only after an incident — a pattern of one person requesting the same credential weekly usually means the access model is wrong rather than that they are behaving suspiciously.

Related

• Passwords — where credentials are stored and marked as requiring authorization
• Peer roles — who can approve

Requesting, confirming and reviewing

Three further screens carry the request itself:

Screen	Who sees it
Privileged Access Request	The requester
Privileged Access - Request Confirmation	The requester, confirming what was submitted
Privileged Access Request Review	The authorizer, deciding
Privileged Access History	Anyone auditing what was granted before

A request may also carry a Two-Form Code step, and the outcome is notified separately to the user and to the authorizers — see the Documentation mail templates.

Turning the notifications off does not turn the approvals off

The approval step is enforced by the feature; the mail templates only tell people about it. Disable them and requests still queue — they simply queue silently, with nobody informed there is a decision waiting.

If technicians report that privileged access requests “never get answered”, check the templates before the authorizer list.