Four Azure Sign-In Log Bypasses In, and the Architecture Behind All of Them

Four bypasses. That is where we are with Azure’s sign-in logging. TrustedSec has published a disclosure of a third and fourth method for authenticating to Microsoft Entra ID (formerly Azure AD) without generating a sign-in log entry. This follows two prior findings from the same research team, which means this is no longer a story about individual bugs. It is a story about an architecture that consistently fails to capture authentication events across certain code paths.

In the Microsoft identity ecosystem, sign-in logs are the primary audit trail for authentication events. They live in a handful of Azure Monitor tables exported to Log Analytics workspaces, and ingested by Microsoft Sentinel or third-party SIEMs:

SignInLogs: Interactive user authentications
NonInteractiveUserSignInLogs: Token refreshes, silent auth flows, delegated access
ServicePrincipalSignInLogs: App-to-app authentication via client credentials or certificates
ManagedIdentitySignInLogs: Authentication by Azure-managed service identities

Every SOC analyst monitoring a Microsoft environment knows these tables. KQL queries like the following are bread-and-butter detection logic in Sentinel workbooks, custom analytics rules, and incident response playbooks:

SignInLogs
| where ResultType != 0
| where UserPrincipalName contains "target@domain.com"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ResultDescription

When an attacker gets a foothold in Microsoft 365 or Azure, the sign-in logs are almost always the first place responders look to understand scope and timeline. The bypasses TrustedSec has found mean that an attacker could authenticate to Azure resources in ways that leave none of these tables with a corresponding entry. From an incident response standpoint, that is a significant gap.

The Authentication Landscape That Has to Be Covered

Modern Azure authentication is not a single system. It is a collection of protocols and flows that have accumulated over years:

OAuth 2.0 authorization code flow (interactive, browser-based)
OAuth 2.0 client credentials flow (app-to-app)
Resource Owner Password Credential (ROPC) grant
Device authorization grant (device code flow)
On-behalf-of (OBO) flow for service chaining
SAML assertion grants
Kerberos-based Seamless SSO via autologon.microsoftazuread-sso.com
WS-Trust for legacy federation scenarios
Pass-through authentication via on-premises agents

Each of these flows takes a different path through Microsoft’s backend. They involve different services, different token issuance endpoints, and different internal components. The logging infrastructure has to explicitly hook into each path to generate sign-in records. When a new flow is added, or when an existing flow interacts with another service in an unanticipated way, authentication can succeed without the logging hook firing.

That is the structural problem. Microsoft’s authentication layer and Microsoft’s logging layer are not the same system. Every authentication path has to be individually wired to produce audit records. Miss one, and you have a bypass.

Prior Research Built the Foundation

The TrustedSec disclosure is the third publication in what has become a research series. Their earlier work identified that certain authentication paths could complete without entries appearing in the standard log tables, even with diagnostic settings configured and log export enabled in the tenant.

The Seamless SSO endpoint is worth examining as a particularly tricky case. When a Windows device on a domain-joined network authenticates to Azure, it can use a Kerberos service ticket against autologon.microsoftazuread-sso.com. Microsoft designed this to make the experience transparent to users. The security implication is that an attacker who has compromised on-premises Active Directory and can forge or steal Kerberos tickets can pivot to cloud authentication using the same mechanism, and depending on configuration, this can happen with reduced or absent log visibility. This created a natural bridge between on-premises compromise and cloud lateral movement that the logging architecture did not anticipate.

The ROPC grant is another historically underlogged flow. ROPC allows a client to send a username and password directly to the token endpoint without a browser redirect. Microsoft discourages it for modern applications but still supports it for compatibility. In certain configurations, ROPC authentications ended up in NonInteractiveUserSignInLogs rather than the primary SignInLogs table. Many tenants either had not enabled the diagnostic setting to export that table, or their SIEM configuration did not ingest it, effectively making those authentications invisible to detection rules targeting the main sign-in table.

The device code flow has a similar character. It was designed for input-constrained devices like smart TVs, but it has been widely abused in phishing campaigns precisely because it can produce tokens through an authentication interaction that bypasses some of the monitoring assumptions defenders build around interactive browser-based logins.

What “Full Disclosure” Signals

The “full disclosure” framing in the TrustedSec title matters. It means Microsoft was informed and either has not addressed the issue, considers it working as intended, or has not committed to a fix within a timeframe the research team found acceptable. This is a meaningful distinction from coordinated disclosure where a patch lands before publication.

Four separate sign-in log bypasses, with the third and fourth published as full disclosure, is a message about the remediation process as much as the technical findings. It suggests the underlying architectural issue is not being treated with the urgency the researchers think it warrants.

This is not unusual territory for Microsoft security research. The company manages an enormous authentication infrastructure with significant backward compatibility requirements, which makes quick architectural changes difficult. But the logging gap compounds over time. Every month these bypasses remain functional, any attacker who knows about them can operate with reduced audit trail exposure.

This also matters for compliance. Frameworks like SOC 2, ISO 27001, and HIPAA technical safeguards often require demonstrable authentication audit trails. If those trails can be bypassed by an attacker who knows specific authentication flows, the compliance claim rests on an incomplete foundation, which creates downstream liability questions that security teams rarely want to hand to their auditors.

What Defenders Can Do Now

Enable all diagnostic log categories. Entra ID diagnostic settings need to be explicitly configured to export NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, and ManagedIdentitySignInLogs in addition to the primary SignInLogs table. Microsoft adds new log categories over time, and many tenants configure diagnostics once during initial deployment and never revisit them. Checking Microsoft’s current documentation on Entra diagnostic settings against your tenant’s actual configuration is worth doing on a schedule.

Correlate with network and endpoint telemetry. If sign-in logs are bypassed, the authentication still happens over the network. TLS handshakes, DNS queries to login.microsoftonline.com or autologon.microsoftazuread-sso.com, and token usage in downstream API calls all leave traces. Microsoft Defender for Endpoint, network flow logs, and proxy logs can surface authentication activity that the identity layer missed.

Monitor token usage downstream. Even if an initial authentication does not log, the token that results from it gets used. Calls to the Microsoft Graph API, Exchange Online, SharePoint, and other services generate their own logs, typically in AuditLogs and application-specific audit tables. Anomalous access patterns in those logs can surface sessions that bypassed sign-in logging entirely.

Cross-correlate Graph activity against sign-in records. The Microsoft 365 Unified Audit Log captures events at the application layer rather than the authentication layer. An attacker who authenticates without logging can still trigger UAL events when performing actions in M365 services. The following query illustrates the pattern of looking for Graph API activity that cannot be correlated back to a known sign-in event:

MicrosoftGraphActivityLogs
| where TimeGenerated > ago(24h)
| join kind=leftouter (
    SignInLogs
    | where TimeGenerated > ago(24h)
    | project CorrelationId, SignInTime=TimeGenerated
) on $left.SignInActivityId == $right.CorrelationId
| where isempty(SignInTime)
| project TimeGenerated, UserId, RequestUri, IPAddress, UserAgent

This will not catch everything, but Graph activity without a corresponding sign-in record is a meaningful anomaly worth investigating. The two log sources are complementary; neither is a complete substitute for the other.

Consider token-level monitoring. Microsoft Entra ID Protection generates risk signals for some anomalous token behaviors, including token replay and impossible travel. These signals operate on the usage side of the token lifecycle rather than the issuance side, which makes them somewhat orthogonal to sign-in log bypasses. They are not comprehensive, but they add a detection layer that does not depend on the initial authentication event being captured.

The Broader Implication

What this research series reveals is that treating Azure sign-in logs as ground truth for whether an authentication occurred is a mistake. They are a good-faith approximation that covers most scenarios most of the time. But the authentication surface in a modern Microsoft environment is wide enough, and the logging hooks are inconsistent enough, that relying on them as a complete record creates blind spots.

Microsoft will presumably address the specific mechanisms TrustedSec has identified, as they have with prior findings. But until authentication and logging are architecturally coupled in a way that makes bypassing one impossible without bypassing the other, researchers will keep finding new paths through the gap. The authentication attack surface grows with every new protocol addition and every new enterprise integration scenario. The logging infrastructure, patched reactively, will always be running behind.

For organizations, the takeaway is not to abandon sign-in logs but to stop treating them as the ceiling of their detection capability. They are a valuable starting point for investigation, not a complete record of what happened. Layer them with network telemetry, downstream application logs, and token usage monitoring. Build detection logic that assumes the authentication record might be missing and asks what else can corroborate or contradict a hypothesis about attacker presence.

Sign-in logs are useful. They are not sufficient, and four bypasses in, that distinction is now well established.