Privileged Access Management Pack — Guide

Privileged Access Management

Attackers do not need to break in if they can sign in as an administrator. Most serious incidents pass through a privileged account at some point: a daily account with local administrator rights, a service account whose password never changes, an administrator who reads email on the same account that runs the directory. A privileged access management platform helps, but it is not where you start. This pack sets out the controls that matter most and shows how to run each one with the tools you already have.

Is this for you?

This pack is for you if:

• your administrators use one account for email, browsing and administration;
• nobody could list every service account, or say who owns each one;
• your emergency administrator password was sealed years ago and has never been tested;
• a leaver’s administrator account has outlived their daily account.

Three tiers of administration

Every system belongs to a tier, and every administrator account belongs to one tier. An account of a higher tier never signs in to a system of a lower tier, because its credential could be captured there.

Every privileged sign-in uses a phishing-resistant method: a security key, a passkey on a managed device, or a certificate. Codes by text message, one-time codes and push approvals are not accepted for privileged access. Nobody approves their own elevation, and a daily account holds no administrator rights anywhere.

How it runs in practice

Take a distributor with 900 staff. Its August ransomware incident started on a warehouse office PC whose user had local administrator rights, one of 146 daily accounts that had them. Its September access review then found a Tier 0 administrator account belonging to an engineer who had left ten weeks earlier. The firm approved its privileged access standard on 18 September and, from 21 September, put every Tier 0 administrator on security keys and time-limited elevation, with a weekly review of Tier 0 activity.

The first reviews found three things. A warehouse system service account had no owner, could sign in interactively, had kept the same password since 2019, and was used by the supplier’s support staff. A break-glass account used on 5 September had its password changed the next working day, but nobody reviewed what it did until 25 September, 14 working days late, because each side thought the other would. And an engineer whose one account held Tier 0 and Tier 1 rights signed in to a file server while her Tier 0 elevation was active. Her password was changed that day and the account is being split in two. At 30 September the firm has 18 privileged accounts, down from 22; 2 of 5 Tier 0 and Tier 1 administrator accounts are just-in-time, with the rest moving on 19 October; 7 of 8 shared, service and break-glass credentials are within their rotation period; and 38 daily accounts still have local administrator rights, all due to go by 31 October.

Start with these three

1. Privileged & Service Account Inventory: every privileged account, human and non-human, with its owner, tier, credential and rotation.
2. Privileged Access Standard: the eighteen rules, the tiers, the approvals and the rotation periods.
3. Break-Glass Account Control Checklist: how many emergency accounts, where they are kept, how they are watched, and what must happen after every use.

Your first month

What to report

Report these every month to the security and IT leadership team, and take any that is outside tolerance to the executive committee with its plan:

• privileged accounts, by tier;
• Tier 0 and Tier 1 administrator accounts on just-in-time access;
• daily accounts that still have administrator rights;
• shared, service and break-glass credentials changed on time;
• privileged access reviews on time, as the user access review pack counts them;
• break-glass uses reviewed within a working day, and session reviews done on time.

Everything in the pack

Adapting it

• Small organisation: one person may hold a Tier 0 and a Tier 2 account, but never one account for both. Where the only other administrator is the requester, the Head of Information Security or, where there is none, an executive approves the elevation, and someone outside IT, such as your monitoring provider, reviews the sessions.
• IT run by an outside provider: the provider’s engineers get named accounts, enabled only for the agreed windows, and the contract’s access clause from the third-party security pack applies. You keep the break-glass accounts yourself.
• Cloud only: the identity tenant is your Tier 0. Use its time-limited role assignment where your licence includes it; otherwise assign by ticket with an end time, use a scheduled task to remove the right, and check every day that removal worked.
• Financial entity: DORA’s technical standards ask for privileged, emergency and administrator access on a need-to-use or ad hoc basis, and for dedicated administrator accounts where possible. This pack’s just-in-time and separate-account rules are written to that level.

Where it maps

• ISO/IEC 27001:2022: Annex A 8.2.
• NIST CSF 2.0: PR.AA-05.
• NIS2: Article 21(2)(i) and (j).
• DORA: Article 9(4)(c).