Are unsuccessful logins to administrative accounts logged and alerted on?
Failed logins against ordinary accounts are background noise. Failed logins against administrative accounts almost never are.
What the carrier is actually asking
The carrier is asking whether unsuccessful authentication attempts against administrative accounts are recorded and whether they generate an alert. It is asking about early detection of credential attacks.
Why it is underwritten
Password spraying and brute force against administrative accounts precede compromise. The signal-to-noise ratio is unusually good, because legitimate administrators rarely fail authentication repeatedly. Detecting at this stage is detecting before anything has happened.
Where the answer lives in Microsoft 365, Entra ID, and Azure
This is measurable in Entra ID, where sign-in logs and alerting are both configurable.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Entra ID | Sign-in logs filtered to failures against privileged accounts | Failures visible and queryable, which requires the logs to be exported for any useful retention |
| Entra ID | Identity Protection risk detections including password spray | Enabled and routed, since it detects the distributed pattern that per-account thresholds miss |
| Entra ID | Alert rules on repeated failures for privileged roles | An alert rule that fires, delivered to a monitored destination |
| Entra ID | Smart lockout configuration | Lockout tuned so attacks are blocked without locking out legitimate administrators |
| On-premises | Domain controller failed logon events forwarded centrally | The on-premises equivalent, since attacks against Active Directory produce no cloud events. Attested |
A spray attempts one or two passwords against thousands of accounts, so no individual account crosses a failure threshold. Detection requires looking at the aggregate: many accounts, few attempts each, one source. Identity Protection does this natively and most home-grown rules do not.
What a defensible yes requires
- Failed authentication against privileged accounts is logged and retained.
- Alerts fire on repeated failures and on distributed spray patterns.
- Alerts reach a monitored destination with an owner.
- On-premises directory failures are collected as well as cloud ones.
- The alert has been tested and someone knows what to do when it arrives.
How this answer goes wrong
Logging exists and no alert is configured, so the evidence is available afterwards and nothing happens at the time. Or an alert exists with a per-account threshold that a spray never crosses, which produces confidence and no detection.
Frequently asked
What threshold should we use?
Low for privileged accounts, because legitimate repeated failure is rare. Combine it with an aggregate rule to catch spray patterns that per-account thresholds miss.
What about successful logins from unusual locations?
At least as valuable. Identity Protection covers it, and it is the detection that catches a successful compromise rather than an attempted one.
Does lockout replace alerting?
No. Lockout blocks the attempt and tells nobody. The alert is what starts an investigation into where the attack came from.
How do we test it?
Deliberately fail authentication against a test privileged account and confirm the alert arrives and reaches a person. It takes minutes and is regularly revealing.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture