- Privileged-role exports from the identity provider and each cloud service
- Local administrator and root account lists from servers, network gear, and OT engineering workstations
- The MSP's list of accounts it holds in your environment, requested in writing
ATL-013INVENTORYEDITORIAL REVIEW COMPLETE
Privileged Account Inventory
Every account that can change systems, security settings, or other people's access — human and service — with a named owner, an MFA method, a last-used date, and a written justification. The accounts attackers want most, on one reviewable page.
Using this artifact
Purpose, inputs, and completion
Purpose. Privileged accounts are the shortest path from one compromised mailbox to a company-wide incident, and most small organizations cannot produce a complete list of theirs on demand. This inventory is that list: every account that can change systems or grant access, each with a named owner, an MFA method, a last-used date, and a justification. It is the input the access review, the MFA tracker, and the offboarding checklist all depend on.
When to use it. Agree on the definition of privileged in the first section before collecting anything, or every contributor will bring a different list. Populate from exports and sign-in logs rather than memory, and include OT engineering software and vendor accounts — the rows most often missing are the ones most worth having. Review quarterly, and update within a day whenever an admin leaves or changes role; the quarterly cycle is a floor, not a trigger.
- Define privileged broadly before you start: tenant and domain admins, local admins, root, network-device logins, OT engineering software accounts, and any account that can grant access to others.
- List service accounts with the same rigor as human ones — every service account gets a named human owner, because 'the backup account' cannot answer questions.
- Record the MFA method per account, not per person; the admin whose daily account has a security key but whose admin account has none is the finding this table exists to catch.
- Fill the last-used column from sign-in logs, not memory; a privileged account unused for 90 days is a removal candidate, not a keepsake.
- Write a one-line justification for every row; if the justification cannot be written, the privilege cannot be kept.
Keeping it honest
Evidence, validation, and failure modes
- A dated register of every privileged account with owner, MFA method, and justification
- A service-account list showing interactive login disabled, vaulting, and rotation dates
- A removal log tying departures and role changes to same-week privilege removals
- Export today's privileged-role membership from the identity provider and diff it against this table; any account in the export but not the table means the maintenance trigger is broken.
- Attempt an interactive sign-in with one service account in a test window; if it succeeds, the no-interactive-login claim in this document is false.
What looks done but is not
- The inventory covers the cloud tenant but not local admins on servers, network gear, or OT engineering workstations — the places attackers actually persist.
- Service accounts are owned by 'IT' collectively, which means nobody rotates them and nobody notices when one starts logging in interactively.
- Vendor and MSP accounts are missing entirely because nobody asked the vendor what accounts it holds.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain every quarterly version for at least two years; who held privilege when is precisely the question an incident investigation asks first.
Full document
Preview — exactly what prints
INVENTORY · IDENTITY & ACCESSv1.0 · REVIEWED 2026-08-06
Privileged Account Inventory
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Privileged accounts are the shortest path from one compromised mailbox to a company-wide incident, and most small organizations cannot produce a complete list of theirs on demand. This inventory is that list: every account that can change systems or grant access, each with a named owner, an MFA method, a last-used date, and a justification. It is the input the access review, the MFA tracker, and the offboarding checklist all depend on.
How to use it
Agree on the definition of privileged in the first section before collecting anything, or every contributor will bring a different list. Populate from exports and sign-in logs rather than memory, and include OT engineering software and vendor accounts — the rows most often missing are the ones most worth having. Review quarterly, and update within a day whenever an admin leaves or changes role; the quarterly cycle is a floor, not a trigger.
What counts as privileged here
Write the local definition down so the table's completeness can be judged against it. When in doubt, a class of account goes in.
Account classes in scope
Check each class off as its accounts are collected — an unchecked class is an admitted gap, which is better than a silent one.
- Cloud tenant and directory administrator roles (global, security, user, billing admins).
- Local administrator and root accounts on servers and workstations.
- Network and firewall device logins, including the shared ones you intend to eliminate.
- OT engineering software accounts and controller access — anything that can change a running process.
- Collected with the plant leader; production access lists are verified with the process owner, not assumed from IT records.
- Service accounts, API keys, and automation identities with elevated rights.
- Vendor and MSP accounts, standing or on-demand, in any of the above.
Privileged account inventory
One row per account, not per person — the same admin's three accounts are three rows with three MFA answers.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Account | System / scope | Privilege level | Human or service | Owner (named person) | MFA method | Last used | Justification | Review date |
|---|---|---|---|---|---|---|---|---|
| EXAMPLE: adm-jrivera | Business cloud tenant | Global administrator | Human | J. Rivera | Phishing-resistant (security key) | 2026-08-03 | One of two tenant admins; separate from daily account | 2026-10-01 |
| EXAMPLE: svc-backup | Backup platform → file servers | Read all shares | Service | T. Okafor (IT leader) | n/a — interactive login disabled, credential vaulted | 2026-08-05 (scheduled job) | Nightly backup job | 2026-10-01 |
Service account handling
Service accounts outlive projects, admins, and sometimes the systems they served. These rules keep them from becoming permanent unattended keys.
Standing rules for every service account
- Interactive login disabled wherever the platform allows it; a service account seen at a login screen is an incident indicator, not a convenience.
- Credential stored in a vault or secrets manager — never in a script, a wiki page, or a shared spreadsheet.
- Rotation on a written schedule (90 days is a common starting point), and immediately when anyone who knew the credential leaves.
- A named human owner accountable for the account's scope and renewal — recorded in the table above.
- Scope reduced to the specific systems and permissions the job needs; 'domain admin because it was easier' is the debt this document retires.
When rotation is genuinely hard
Some legacy and OT-adjacent systems make credential rotation painful or risky. The honest entry is a documented exception with an owner, a compensating measure (isolation, monitoring for interactive use), and an expiry date — not a silent decision to skip the row.
Removals and follow-ups
Accounts flagged unused, unjustified, or over-scoped land here with a removal or reduction date. The removal log doubles as evidence the inventory drives action.
Actions
| Account | Finding (unused / unjustified / over-scoped / no MFA) | Action and owner | Complete by / completed on |
|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | Identity admin |
| Approval authority | IT leader |
| Review frequency | Quarterly, and within one business day of any admin departure or role change |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain every quarterly version for at least two years; who held privilege when is precisely the question an incident investigation asks first. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.