Created by Claude - please verify

Disguised service accounts - heuristics over sign-in activity, naming, password age, MFA registration and Conditional Access coverage; review each row, it is not a verdict.

Required Microsoft Graph permissions

User.Read.All AuditLog.Read.All UserAuthenticationMethod.Read.All Policy.Read.All — application permissions, granted to the app registration with admin consent.

Licence: Microsoft Entra ID P1 (sign-in activity).

Endpoints: GET /v1.0/users (passwordPolicies, lastPasswordChangeDateTime) · GET /v1.0/users?$select=signInActivity · GET /v1.0/reports/authenticationMethods/userRegistrationDetails · GET /v1.0/identity/conditionalAccess/policies

A row needs a service-style name or non-interactive-only sign-ins, plus at least one more signal. Replace such accounts with a managed identity or service principal, or put them behind a Conditional Access policy for workload locations.

If a permission is missing, this report shows a red load error with the Graph status code — not an empty table.

Service Accounts Disguised as Users

Scanners, sync tools and old integrations often run as ordinary user accounts: a password that never changes, excluded from MFA, signing in only from scripts. They are prime targets for password spray and never show up in the service principal reports. Accounts that sign in only non-interactively and have no MFA protection are listed first.

No member account looks like a service account.