We value your privacy

We use cookies to analyze site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Audit and compliance
  3. Privileged access audit
Privileged access audit for US businesses

Count the administrators first. Then go and count the service accounts, the supplier logins, and every local account sitting on every server you own.

The point of the exercise is to find every route to elevated capability, and the directory holds only some of them. What actually belongs on the list is the service account with no owner, the supplier account nobody has reviewed since it was issued, the local account whose password has never changed, and the automation credential living inside a script on a file share.

Book a privileged access auditSee what we look for
Privileged access audit for US organizations
  • Every pathNot only directory administrators
  • CIS 5, 6 and 8Accounts, access control, audit logging
  • Service accountsThe population nobody has an owner for
  • Break-glassVerified by signing in, not by reading
What we examine

Seven distinct privileged populations exist. In most organizations, only the first one has ever been counted.

Version 8.1 of the CIS Critical Security Controls puts account management at control 5, access control management at control 6 and audit log management at control 8. Taken together those three describe exactly what this audit measures. The standard has never been the hard part. Finding every population it applies to is.

Directory administrators, which everybody counts

Global administrators, domain administrators, and everything in the tiers underneath. This is the one list a business can put together when asked, and it almost always turns out bigger than whoever compiled it expected once the nested groups are flattened out. It is also the only list most organizations ever review, which is precisely why an audit that stopped here would be worthless.

Service accounts, which almost nobody owns

Every application, backup job, integration and migration leaves accounts behind. They typically hold more privilege than the work ever needed and carry passwords set on the day they were created. Counting them is not the useful question. The useful question is how many have a named human who could tell you what breaks the moment that password is rotated.

Local accounts on servers and appliances

Local administrator on the Windows servers. Root and sudo on the Linux boxes. The built-in accounts on switches, storage arrays, hypervisors, backup appliances and the building management system. None of them live in the directory, which means no directory-based review has ever seen them, and in a great many estates they all share one password.

Vendor and support access

An account handed to a supplier for support. A remote access tool installed for a project that finished. Standing credentials given to an integrator several years and two staff changes ago. This population is rarely documented, usually still live, and every entry in it is a path into your systems that runs through a company whose security controls you have no say over.

Cloud and platform privilege beyond the directory

Subscription owners, role assignments made at resource level, who can open a key vault, application registrations carrying high consent, and the service principals and managed identities holding more permission than their workload has ever used. Your directory administrator list tells you nothing whatsoever about who is able to delete a production resource group, and that has become the more consequential question of the two.

Standing versus elevated on demand

Counting who holds privilege is only half of it. The audit also records whether they hold it permanently or activate it when there is a reason to. Permanent assignment remains the norm almost everywhere, and changing it moves the risk position further than any other single finding, because a standing target becomes a time-limited one.

Whether any of it is logged and looked at

Control 8 covers audit log management, and privileged activity is where that control earns its keep. Three questions follow from it. Are privileged sign-ins and actions logged at all. Are those logs kept long enough that an investigation is possible. And would anyone actually notice an unexpected one. It is the third question that organizations fail.

The population nobody can name an owner for

The biggest privileged population in your estate is service accounts, and it is the one nobody governs.

Ask for a list of administrators and any business can produce one. Ask for a list of service accounts with a named owner beside each entry and almost none can.

  • Each one gets created for a job, granted whatever privilege made the job start working rather than the privilege the job actually needed, and then left alone permanently, because touching it risks breaking whatever it quietly runs.
  • Their passwords usually date from the day they were created, and the reason is always the same: nobody can say with any confidence what stops working if it changes. It is exactly the asymmetry that keeps obsolete firewall rules in place, transplanted onto credentials.
  • They are simultaneously the accounts least likely to carry multifactor authentication, most likely to be carved out of conditional access, and most likely to be written in plain text into a script, a scheduled task or a configuration file that a great many people can read.
  • What breaks this cycle is not a number. It is a list carrying a named owner against every account, a plain statement of what each one does, and a rotation plan for those where the owner can confirm the blast radius. Building that list accounts for most of the effort in the engagement and essentially all of the value.
Ask us to inventory your service accounts
How we approach it

Four things that separate this from handing you a list of administrators.

Pulling a list of directory administrators takes a few minutes and is the least valuable form this work can take. Everything worth paying for sits in the populations that are harder to enumerate and correspondingly easier to leave alone.

We inventory service accounts and chase every owner

In most businesses this is both the largest privileged population and the one under the least governance. A count achieves nothing. What matters is a list carrying a named owner, a stated purpose, and an honest assessment of what a rotation would take down. You cannot query a directory for that. It comes from sitting down with the application teams.

Our attention goes outside the directory, which is where most of the estate actually is

Local accounts on servers. Linux sudoers files. Credentials on network devices. Hypervisor and storage consoles. Backup systems. Database logins. Building management. A directory review sees none of them, every one of them grants privilege, and several grant more than any directory role could, for the simple reason that they sit underneath the directory rather than inside it.

We test the break-glass accounts by using them

The guidance on emergency access accounts leaves little room for interpretation. At least two of them. Cloud-only, on the onmicrosoft.com domain. Phishing-resistant authentication that differs from what the normal administrative accounts use. Permanently active in Privileged Identity Management rather than eligible. Excluded from any Conditional Access policy that could block them. Alerted on. And validated no less often than every ninety days. We verify that last point by actually signing in, not by reading a configuration screen and assuming.

The question we ask is whether anyone would notice, not merely whether it was recorded

Control 8 is audit log management, and privileged activity is where it earns its place. Plenty of organizations log privileged sign-ins. Rather fewer keep those logs long enough for an investigation to be possible. Almost none have somebody who would spot an unexpected privileged sign-in at three in the morning, and that last point is what separates an actual control from a filing cabinet.

Where this matters most

Six US situations where a privileged access audit changes the picture.

Nothing gets an attacker from the outside to everything that matters faster than privileged access. That is why it is the population they go after, and it is also the population businesses undercount more consistently than any other.

A regulated firm asked to evidence privileged access control

A SOC 2 examination, a HIPAA security assessment, NYDFS Part 500 and the FTC Safeguards Rule all want the same four things from privileged access: that it is restricted, justified, monitored and reviewed on a schedule. Respond with a directory administrator list and you have addressed a fraction of the privileged estate. The full audit answers for every population, and that is what each of those questions is really asking even where the wording never says so.

A group that has grown by acquisition

Every acquisition arrives with a directory of its own, its own service accounts, its own supplier relationships and its own habits around local accounts. Integration then usually bolts on cross-domain trust or synchronization without anybody auditing what privilege that quietly grants. Nobody assembles the combined picture unless somebody is told to, and a diligence team on the buying side will eventually ask for exactly that picture.

An organization with heavy supplier and integrator involvement

Supplier accounts, support access and remote tools installed for projects pile up steadily and get removed almost never. Every one of them is privilege inside your environment held by a company whose security controls you have no visibility into, which makes each entry a security question and a third-party risk question at once.

An operator with technology outside the IT estate

Building management, door access control, plant systems and facilities technology all sit on the network, all hold privilege over things with physical consequences, and almost none of them ever appear in an identity review. Default credentials are common, for a straightforward organizational reason: IT does not regard them as its responsibility and facilities does not regard them as a security asset.

An organization that has just had an identity incident

Once an account is compromised the first question is what it could reach. The second and larger question is what else in the estate has comparable reach, and only a full privileged inventory answers that. Most organizations commission this work in the weeks after an incident, when it costs considerably more than it would have beforehand.

A business implementing just-in-time privileged access

Before standing privilege can become on-demand privilege, somebody has to know what standing privilege exists, including the parts that cannot move at all because they are service accounts or appliance logins. The audit has to come first, and what it generally reveals is that the human administrators were the straightforward half of the problem.

Three positions

How US organizations understand their privileged access.

Most organizations sit in the middle column, and it is genuinely better than nothing. What it does is answer the question for the directory while leaving every other route to privilege unexamined.
Directory administrators known
Full privileged access auditYes
Directory administrators reviewedYes
No privileged access reviewNo
Service accounts inventoried with owners
Full privileged access auditYes
Directory administrators reviewedNo
No privileged access reviewNo
Local and appliance accounts covered
Full privileged access auditYes
Directory administrators reviewedNo
No privileged access reviewNo
Vendor access documented
Full privileged access auditYes
Directory administrators reviewedNo
No privileged access reviewNo
Cloud resource privilege included
Full privileged access auditYes
Directory administrators reviewedRarely
No privileged access reviewNo
Standing versus on-demand recorded
Full privileged access auditYes
Directory administrators reviewedNo
No privileged access reviewNo
Credential age known
Full privileged access auditYes
Directory administrators reviewedPartly
No privileged access reviewNo
Break-glass accounts tested
Full privileged access auditYes
Directory administrators reviewedNo
No privileged access reviewNot applicable
Privileged activity monitored
Full privileged access auditYes
Directory administrators reviewedLogged only
No privileged access reviewNo
Answer to who could do the most damage
Full privileged access auditYes
Directory administrators reviewedPartial
No privileged access reviewNo
Feature
Full privileged access audit
Directory administrators reviewed
No privileged access review
Directory administrators known
YesYesNo
Service accounts inventoried with owners
YesNoNo
Local and appliance accounts covered
YesNoNo
Vendor access documented
YesNoNo
Cloud resource privilege included
YesRarelyNo
Standing versus on-demand recorded
YesNoNo
Credential age known
YesPartlyNo
Break-glass accounts tested
YesNoNot applicable
Privileged activity monitored
YesLogged onlyNo
Answer to who could do the most damage
YesPartialNo
The questions per account

Nine questions, asked of every privileged account we find.

Every account gets an answer against each of these. Most businesses handle the first two without difficulty and start struggling at the third.

Question

Who is the named owner?

Why it matters
Without a named owner an account can never be reviewed, altered or switched off

Question

What is it for?

Why it matters
Purpose determines whether the privilege level is proportionate

Question

Does the privilege match the purpose?

Why it matters
Most over-privilege is historic rather than deliberate

Question

Is it standing, or activated on demand?

Why it matters
Standing privilege is a persistent target

Question

How does it authenticate?

Why it matters
Phishing-resistant, multifactor, a password on its own, or a key sitting in a file

Question

When did the credential last change?

Why it matters
And does anybody know what rotation would break

Question

When was it last used?

Why it matters
Unused privileged accounts are the cheapest thing to remove

Question

Is its activity logged?

Why it matters
Control 8 covers audit log management, and privileged activity is where it counts

Question

Would anyone notice unexpected use?

Why it matters
Logging without review is storage, not detection
QuestionWhy it matters
Who is the named owner?Without a named owner an account can never be reviewed, altered or switched off
What is it for?Purpose determines whether the privilege level is proportionate
Does the privilege match the purpose?Most over-privilege is historic rather than deliberate
Is it standing, or activated on demand?Standing privilege is a persistent target
How does it authenticate?Phishing-resistant, multifactor, a password on its own, or a key sitting in a file
When did the credential last change?And does anybody know what rotation would break
When was it last used?Unused privileged accounts are the cheapest thing to remove
Is its activity logged?Control 8 covers audit log management, and privileged activity is where it counts
Would anyone notice unexpected use?Logging without review is storage, not detection
How an engagement runs

Five steps, of which the second consumes more time than the other four combined.

Three to six weeks is typical. Where the systems are reachable, enumeration moves quickly. What sets the timeline is attributing ownership to service accounts, because that work needs conversations with people rather than queries against systems.
  1. 1

    Enumerate every privileged path, not only the directory

    We enumerate directory roles with every nested group flattened out, local administrators on servers, root and sudoers on Linux, database logins, accounts on network devices, hypervisor and storage consoles, backup systems, cloud subscription and resource roles, application registrations and service principals, plus whatever facilities or operational technology falls inside the agreed scope.

  2. 2

    Attribute ownership, especially for service accounts

    We sit down with the application and platform teams and put a named owner and a stated purpose beside every account. It is the slowest part of the engagement, and it is what decides whether you receive a list of decisions or merely a census. Any account that comes out of this step still without an owner is a finding in its own right.

  3. 3

    Assess proportionality, standing privilege and credential hygiene

    Five things per account: whether the privilege actually matches the stated purpose, whether it is standing or activated on demand, how it authenticates, when its credential last changed, and when anyone last used it. That final field matters more than it sounds, because unused privileged accounts are both the cheapest remediation available and, reliably, the largest single category in the report.

  4. 4

    Test break-glass and check monitoring

    We sign in to every emergency access account rather than reading its configuration and hoping, and we confirm the alert actually fires. From there we check whether privileged sign-ins and actions are logged, whether those logs survive long enough to investigate with, and whether anyone reviewing them would spot something that did not belong. That last one is where organizations usually come unstuck.

  5. 5

    Deliver a prioritized remediation plan with owners

    Unused accounts get removed. Over-privileged ones get scoped down. Standing privilege becomes on-demand wherever the account type permits it. Credentials rotate wherever an owner can confirm what that affects. Supplier access is documented and given an expiry. Every item carries a named owner, because a privileged access report without owners against its findings changes precisely nothing.

Straight answers

What US organizations ask about privileged access audits.

That is the smallest piece of the work and the one you could do yourself this afternoon. The audit covers every route to elevated capability there is: service accounts, local administrators on servers, root and sudo on Linux, database logins, accounts on network and storage devices, hypervisor consoles, backup systems, cloud resource roles, application registrations, supplier access, and the credentials sitting inside scripts and configuration files.

Three reasons. They are the largest privileged population you have. They are governed less than any other. And they are the least likely to sit behind multifactor authentication or conditional access. On top of that they were almost always created with whatever privilege made the thing start working rather than the privilege it genuinely needed, and their credentials go unrotated because nobody can say with confidence what stops if they change.

That is a finding in itself, and it needs a default position agreed before the list exists. In our experience the right default for an unowned privileged account is to disable it in a controlled way and watch what happens, on the basis that turning it back on is easy while leaving it running is the actual risk. Settle that policy in advance and you avoid a drawn out argument over every individual account once the list lands.

Cloud is very much in scope, and it is steadily becoming where the privilege that matters most actually lives. Subscription and resource role assignments, access to key vaults, application registrations holding high consent, service principals and managed identities all hand out capability that no directory administrator list will ever describe. Anyone able to delete a production resource group is privileged, whatever their directory role happens to say.

Standing means the account carries the capability all the time. On-demand means it is switched on when there is a reason, for a bounded period, usually behind an approval and always leaving a record. Making that conversion does not change what a person is able to do. It shrinks the window during which compromising that account is worth anything to an attacker, which is a large gain for a modest amount of work.

We test them by signing in, because nothing else counts as a test. The published guidance is precise about what they should look like: two or more of them, cloud-only on the onmicrosoft.com domain, using phishing-resistant authentication that differs from your ordinary administrative methods, permanently active in Privileged Identity Management rather than eligible, kept outside any Conditional Access policy capable of blocking sign-in, alerted on, and validated at intervals no longer than ninety days.

It is in scope, and it tends to be among the more uncomfortable pages in the report. Support accounts handed out years ago. Remote access tools installed for a project that finished and never uninstalled. Integrator credentials that outlasted the integration itself. Every one of those is privilege inside your environment held by a company whose controls you cannot see or influence, which makes each a third-party risk finding just as much as a technical one.

If agentless machine secrets scanning is available to you, it handles a large share of this on its own, and some cloud workload protection plans include it already. Without it, a targeted search through scheduled tasks, deployment scripts, configuration directories and automation platforms turns up most of what is there. Whichever route we take, the output surprises people every time.

Unused privileged accounts, and a great many of them. Created for a project, for somebody who has since left, for a migration or for a supplier, they still exist, still carry privilege, and have gone untouched for a year or longer. Removing them is the cheapest remediation available, it requires no design decision from anyone, and we have yet to run an audit that did not find them.

An access review runs on a schedule and recertifies whether people should still hold what they hold, and it generally covers whatever the directory governs. This audit is a point-in-time examination of every privileged path there is, including all the ones the directory has no knowledge of. Most businesses need the audit once to establish the picture, then the recurring review to keep it accurate.

Mainly two: account management and access control management, controls 5 and 6 in version 8.1 of the CIS Critical Security Controls. Control 8, audit log management, covers the separate question of whether privileged activity is recorded and looked at. If you are measured against something else, whether that is the SOC 2 criteria, the NIST Cybersecurity Framework, NIST 800-171 or an insurance questionnaire, we map the findings across to it too.

The audit reads and changes nothing. Remediation is where the risk sits, which is exactly why the order matters. Unused accounts go first, because removing them is safe. Over-privilege reduction comes next. Credential rotation happens last and only where an owner can state what depends on that credential. Rotating a service account password without knowing what consumes it is the classic route from privileged access project to unplanned outage.

Between three and six weeks for most businesses. Where systems are reachable, enumeration goes fast. The constraint is attributing ownership to service accounts, which needs conversations with application and platform teams rather than queries against a directory. Those conversations are precisely what separates a census from a list somebody can act on.

Before it, nearly always. Scope a privileged access management deployment from an incomplete inventory and it will protect the accounts you already knew about while leaving everything else exactly as it was. The audit tells you what needs onboarding, which populations cannot be onboarded at all because of what they are, and therefore what the tooling is genuinely going to solve versus what it will not touch.

We do, because that process decides whether anything stays clean once we leave. Four questions matter: who is able to grant privilege, whether an approval stands between the request and the grant, whether the grant is recorded with a reason attached, and whether it expires on its own. Where anyone holding an administrative role can grant privilege with no approval and no record, the estate will be back where it started inside a year no matter how much gets remediated today.

This is one of the more revealing checks we run. The directory account almost always goes promptly, because offboarding covers it. What survives is everything offboarding never knew about: their local account on a server, their line in a sudoers file, their credentials on a network device, their cloud role assignments, and any service account they created under their own name. None of that is part of an HR process. Cross-referencing your leavers against every privileged population takes very little time and produces findings every single time.

Each engagement is scoped on its own, driven by how many platforms and environments are included and how many legal entities are involved. The variable is the service account ownership work, which depends entirely on how much documentation already exists and how many teams have to be consulted. The initial enumeration happens quickly and usually establishes the true size of the job before you commit to anything.
Preparing for the audit

Fifteen sources of privileged access to include in scope.

Scope this to the directory and the report will read comfortably. These are the places privilege genuinely resides, and everything past the first five is where the findings turn up.

The obvious ones

  • Directory administrative roles
    With nested groups expanded.
  • Server local administrators
    Outside the directory, outside most reviews.
  • Linux root and sudo
    Including sudoers entries.
  • Database administrative accounts
    Frequently separate from the directory.
  • Network device accounts
    Often shared, often unchanged.

The ones that get missed

  • Service accounts across all platforms
    The largest population.
  • Application registrations and service principals
    Consent can exceed any human role.
  • Cloud subscription and resource roles
    Not visible in a directory role list.
  • Hypervisor and storage consoles
    Privileged over everything they host.
  • Backup system accounts
    Able to read or destroy everything.

The ones nobody mentions

  • Vendor and integrator accounts
    Usually standing, usually undocumented.
  • Remote access tools installed for projects
    Frequently still running.
  • Break-glass accounts
    Verified by signing in, not by reading.
  • Building and facilities systems
    Privileged, networked, and unowned.
  • Credentials in scripts and config files
    Machine secrets scanning finds these.
Related reading

The pages around this one.

Privileged Identity Management

How standing privilege becomes on-demand privilege in the Microsoft stack.

Learn more

Emergency access accounts

Break-glass design, and how the accounts are validated.

Learn more

Entra access reviews

The recurring recertification that maintains what the audit establishes.

Learn more
Next step

Request a list of every service account you run, with a named owner beside each one.

Making that request costs you a minute, and no other question in this area tells you as much. In most businesses the list either does not exist at all or turns up with the owner column blank. Whichever answer you get is itself the argument for running the audit.

Book a privileged access auditSee audit and compliance services

Related Services

Explore more solutions that work great with this service

Microsoft Entra Privileged Identity Management

Privileged Identity Management deployment for US organizations:

Learn more

Emergency Access Account Design

Break-glass emergency access account programs for US organizations:

Learn more

Microsoft Entra Access Reviews

Entra access review programs for US organizations: entitlement

Learn more

Microsoft Entra Workload Identities

Workload identity governance for US organizations: applications

Learn more

Microsoft Defender for Identity Services

Identity threat detection for Active Directory and Entra

Learn more
GR IT SERVICES

IT services for US businesses,
delivering enterprise-grade solutions
remotely, coast to coast.

Microsoft CSP PartnerApple Jamf PartnerCISGuard

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support USA
  • IT AMC USA
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • hello@gritservices.io
  • gritservices.io

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie PolicyCCPA/CPRA