A security team at TrustedSec recently disclosed their third and fourth methods for bypassing Azure sign-in logging. That's four independent techniques for authenticating to Microsoft cloud services without the authentication appearing in the logs that security teams rely on for detection. The sign-in happened. The logs didn't record it. Anyone monitoring those logs for suspicious activity saw nothing.
This isn't a theoretical problem. If an attacker steals credentials and uses them to access your Azure environment, the first thing your security team does is check the sign-in logs. If those logs are incomplete — if entire categories of authentication don't generate log entries — your detection capability has a hole you didn't know about. And you've been making security decisions based on the assumption that the logs were complete.
Why Authentication Logs Have Gaps
The naive assumption is that authentication logging is simple: someone authenticates, you log it. In practice, cloud authentication is a sprawling system with dozens of protocols, endpoints, and token types — and logging coverage varies across them.
Azure Active Directory (now Entra ID) handles authentication for Microsoft 365, Azure resources, third-party apps via SAML/OIDC, legacy on-premises apps via App Proxy, service principals, managed identities, and more. Each of these authentication paths has its own backend, its own logging pipeline, and its own edge cases. Sign-in logs are generated by the authentication service, but some authentication flows bypass the standard service or use legacy paths that predate the current logging infrastructure.
Legacy Protocol Gaps
Microsoft maintains backward compatibility with authentication protocols from the early 2000s — protocols that predate their modern logging infrastructure. Some SMTP, IMAP, and POP3 authentication paths use 'Basic Auth' flows that authenticate at the mail transport layer rather than through the standard Azure AD token endpoint. These authentications may not generate the same sign-in log entries that modern OAuth/OIDC flows do.
Microsoft has been deprecating Basic Auth for years, but deprecation is slow in enterprise environments. Organizations with legacy mail clients, scanners that email documents, or older line-of-business applications may still have Basic Auth enabled. Each legacy path is a potential logging gap.
Service Principal Authentication
Service principals — non-human identities used by applications and automation — authenticate differently than users. Their sign-in events appear in a separate log stream (service principal sign-ins vs interactive sign-ins vs non-interactive sign-ins). Security teams that only monitor the interactive sign-in log miss service principal activity entirely.
This matters because compromised service principals are a common attack vector. An attacker who obtains a service principal's credentials or certificate can authenticate as that application and access whatever resources it has permission to. If the security team is only watching user sign-ins, they'll never see it.
Token Replay and Refresh
Not every access involves a fresh authentication. OAuth refresh tokens allow continued access without re-authenticating. If an attacker steals a valid refresh token (through a compromised device, intercepted traffic, or malware), they can exchange it for new access tokens without triggering the same sign-in log entries that a password-based authentication would. The initial sign-in was logged, but subsequent token refreshes may appear as non-interactive sign-ins — which many detection rules don't monitor.
The Detection Engineering Problem
Authentication logging gaps reveal a broader problem in cloud security: we build detection systems on top of logs that we assume are complete, and then act surprised when attackers find paths that don't generate logs.
The standard security architecture for cloud environments looks like this: cloud services generate logs → logs flow to a SIEM (Security Information and Event Management system) → detection rules analyze logs for suspicious patterns → alerts trigger investigation. This works only if the logs capture all relevant activity. If they don't, your SIEM is a very expensive way to monitor an incomplete picture.
Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.What You Can Actually Do
You can't fix cloud provider logging gaps — that's Microsoft's (or AWS's, or Google's) job. But you can build detection strategies that don't depend solely on authentication logs being complete.
Monitor Multiple Log Sources
Authentication logs are one signal. Activity logs are another. Even if an attacker's sign-in doesn't appear in authentication logs, their subsequent actions — reading emails, accessing files, querying databases, modifying configurations — generate their own log entries. Cross-correlating activity logs with authentication logs reveals inconsistencies: activity from an identity with no corresponding recent sign-in is suspicious regardless of why the sign-in wasn't logged.
-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5 // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypassDisable Legacy Authentication
If you're not using legacy protocols (Basic Auth for SMTP, IMAP, POP3), disable them. This eliminates entire categories of logging gaps because the authentication paths that bypass modern logging simply can't be used. Azure's Conditional Access policies can block legacy authentication per-user, per-group, or tenant-wide.
Before disabling, audit your current usage. Azure's sign-in logs (ironically) do show some legacy authentication attempts, and the Entra ID workbook for legacy auth helps identify applications still using old protocols. Fix those applications first, then block legacy auth.
Monitor Token Activity
Implement Continuous Access Evaluation (CAE) if your environment supports it. CAE allows Azure AD to revoke tokens in near-real-time when conditions change (user disabled, high-risk sign-in detected, IP location changes). Without CAE, a stolen access token is valid until it expires — typically one hour — regardless of what the security team does.
Also monitor token lifetimes and refresh patterns. A refresh token being used from a new IP address, a new device, or at unusual hours should be flagged — this is often the only signal of token theft.
Test Your Own Logging
The most impactful thing you can do is regularly test whether your logging actually captures what you think it does. Authenticate through each method your environment supports — interactive, non-interactive, service principal, legacy protocol — and verify that each one generates the expected log entries. If it doesn't, you've found a gap before an attacker does.
This is a form of detection engineering testing that few organizations do systematically. Most teams write detection rules and assume they work. Validating the underlying data quality — confirming that the events your rules depend on are actually being logged — is arguably more important than the rules themselves.
The Broader Lesson
The Azure sign-in log bypasses aren't unique to Microsoft. Every cloud provider has authentication paths with incomplete logging. AWS CloudTrail has its own known gaps — certain control plane operations in some regions, certain service-linked role assumptions, and cross-account role chaining patterns that can obscure the original identity. Google Cloud's audit logs have similar edge cases.
The lesson isn't 'Azure logging is broken.' It's that all logging is incomplete, and security architectures that assume otherwise will fail. Defense in depth isn't just about having multiple security controls — it's about having multiple independent sources of visibility. If your detection depends entirely on one log source being complete, you have a single point of failure in your security posture.
Build your detection around the assumption that any individual log source can be incomplete or bypassed. Correlate across authentication logs, activity logs, network logs, and endpoint telemetry. Look for inconsistencies between sources — they often point to exactly the gaps that attackers exploit. And test your logging regularly, because the gap you don't know about is the one that will be used against you.
