Secure Score - gMSA not recognized ("Change service account to avoid cached password in registry")

Hello MarkusQ_oh22,

I asked ChatGPT and got this:

Your situation is not uncommon—many admins run into this false-positive or delay issue after correctly implementing gMSA for SQL Server but still seeing Secure Score report it as an "exposed device." Here’s a breakdown of why this might happen and what steps you can take to validate or resolve it:

What’s Likely Happening
Delayed Secure Score Refresh:
Secure Score assessments are not real-time. It may take 24-72 hours for the backend to re-assess the environment.
Even longer delays can occur if certain telemetry is missing or if signals aren’t being picked up correctly.
Telemetry Source Limitations:
Secure Score's recommendation for cached service account passwords depends on Defender for Endpoint (MDE), not Defender for Identity.
If you don’t have MDE deployed on those SQL Servers, Secure Score cannot verify the remediation (even if it's done correctly).
gMSA Usage Misinterpreted:
Some older versions of telemetry might misidentify the service account as a regular user account, especially if:
The gMSA wasn't correctly set as Log On As for the service.
SQL Server or OS logs show historical use of old credentials.
The gMSA was not registered properly in AD, or the machine account is not allowed to retrieve the gMSA password.

# Confirm the SQL Server service is using a gMSA
Get-WmiObject Win32_Service | Where-Object { $_.Name -like "*SQL*" } | Select-Object Name, StartName

# Check for cached credentials
cmdkey /list

Make sure:

The StartName is in the format DOMAIN\gMSAName$
No cached credentials appear for that gMSA
The gMSA was added with the correct PrincipalsAllowedToRetrieveManagedPassword