Your PingCastle Score Is Red: What to Fix First

PingCastle is the free tool most admins reach for when someone asks "how secure is our Active Directory?" It runs in minutes and produces a report full of red. Then the hard part starts: which of those findings actually matters, and in what order should you fix them without breaking production?

This post covers how the score works (it isn't an average), which findings tend to sit on real attack paths, a fix order that suits a 10–500-person organization, and the changes that are easy to get wrong.

What the score actually measures

PingCastle, now owned by Netwrix ("In 2024, PingCastle was acquired by Netwrix"), scores a domain on four categories. From the Netwrix user guide: "PingCastle calculates an overall security score based on four categories. The maximum score across these categories determines the overall score (maximum 100 points per category)."

• Privileged Accounts: administrator accounts and privileged access.
• Trusts: trust relationships, because "one AD can compromise another via trusts".
• Stale Objects: object lifecycle, "including inactive computers, users, and delegations".
• Security Anomalies: everything that doesn't fit the other three.

Points come from rules: "Each triggered rule displays its severity level and point value." PingCastle's own sample report calls the number a Domain Risk Level, "computed based on the rules that matched during the analysis". So a higher score means more risk.

The detail that trips people up is the word maximum. The overall score is your worst category, not an average. You can clean up hundreds of stale computer accounts, and if Privileged Accounts is still sitting higher, the headline number won't move at all. PingCastle's sample report gives the same advice: "Locate the sub-process determining the score and fix some rules in that area to get a score improvement."

Run it properly first

• A standard account is usually enough. Netwrix: "In most cases, a standard user account with no special privileges is sufficient."
• Privileged mode catches certificate problems. Netwrix lists the rules that "benefit from privileged mode", including "A-CertTempCustomSubject (ESC1) Certificate template vulnerability check", which reads the CA enrollment permissions. If you run Active Directory Certificate Services, a standard-user run can miss the findings that matter most.
• Check the expiry date. "PingCastle only runs until the built-in license expiration date." An old copy on a file share will eventually stop working.
• Entra ID has its own check. The current build has a separate Entra ID option, described as "Score the risk of Entra ID", alongside the domain healthcheck. If you sync to Microsoft 365, run both.

What to fix first: our order

This is the order we work in for a small or mid-sized domain. It's our practitioner judgment, not a ranking from PingCastle or Microsoft. The principle: fix what gives an attacker the domain first, housekeeping last.

1. Privileged Accounts. Too many Domain Admins, admin accounts that also read email, service accounts with domain-level rights, and dangerous delegation. Microsoft's enterprise access model grew out of the AD tier model, which "focused on containing unauthorized escalation of privilege". Shrinking Tier 0 is usually the biggest single risk reduction. See AD Tier-0 in 90 days, and don't forget your remote-management tool is Tier 0 too.
2. Certificate templates. ESC-style template findings can turn an ordinary account into a domain admin. If privileged mode flags one, it goes near the top of the list regardless of its point value.
3. Anomalies that sit on attack paths. PingCastle's scanner flags a remotely active print spooler as "exploitable with unconstrained delegation", so the two findings together matter more than either alone. Missing local-admin password management is another: Windows LAPS "automatically manages and backs up the password of a local administrator account", which removes the shared local password that lets an attacker hop between machines.
4. Trusts. Few small organizations have many, but each one is a path in. PingCastle's methodology recommends you "request SID Filtering on 100% of trusts".
5. Stale Objects. Often the biggest list and the least urgent, with one exception: stale objects that still hold delegation or privileged group membership belong in step 1.

What not to do

• Don't put service accounts in Protected Users. It's a strong control for human admin accounts: members can't "Authenticate with NTLM authentication", can't "Use DES or RC4 encryption types in Kerberos preauthentication", can't "Delegate with unconstrained or constrained delegation", and can't "Renew Kerberos TGTs beyond their initial four-hour lifetime." Microsoft is blunt: "Never add accounts for services and computers to the Protected Users group." Test with one admin account first.
• Don't switch off NTLM or RC4 domain-wide from a report. Inventory what still uses them first. Our Kerberos RC4 triage covers how.
• Don't bulk-delete "stale" accounts. Disable, wait, then delete. Some "inactive" accounts run scheduled tasks or appliances.
• Don't chase the number. A lower score is a side effect. The goal is closing the paths that end at Domain Admin.

What the report can't tell you

PingCastle is an assessment tool, and its makers say so plainly: "Assessment tells you where the risk is. It doesn't fix it, it doesn't stop someone exploiting it, and it can't undo the damage if they do." A report lists findings one by one. It doesn't show which three findings chain together into a working path from a help-desk account to Domain Admin, or from a synced on-premises account into Microsoft 365.

That chaining is the work we do in an Active Directory security assessment: prove which paths are real, fix them in a safe order, and re-run the tests to show they're closed. If your report is red and your team is already stretched, that's where we fit.

A note on licensing: PingCastle's open-source license lets "a company's own IT staff or their contracted IT service providers" use it internally, but "You cannot monetize PingCastle or offer it as a paid service to others under this license." Netwrix sells a separate per-assessment license for service providers. Check the current terms in the PingCastle README before you rely on either.

This is technical guidance based on the published PingCastle documentation and Microsoft Learn as of November 2026, not legal advice. Test each change in your own environment before you make it in production.