Four distinct methods now exist to authenticate against Microsoft’s Azure cloud infrastructure without generating a trace in sign-in logs. Four. The security firm that discovered them says Microsoft has known about most of these gaps for months, and the response so far has ranged from slow patches to quiet indifference.
TrustedSec, a cybersecurity consultancy based in Fairlawn, Ohio, published a full disclosure report detailing what it calls the third and fourth Azure sign-in log bypasses it has identified. The firm had previously disclosed two other bypasses — one in September 2024 and another in January 2025 — both of which allowed attackers to authenticate to Microsoft Entra ID (formerly Azure Active Directory) without those authentications appearing in the logs that defenders rely on to detect compromise. The new findings follow the same pattern but exploit different authentication pathways, widening the attack surface considerably.
This matters because sign-in logs are the primary forensic artifact security teams use to detect unauthorized access, investigate breaches, and trigger automated responses. If an attacker can authenticate and operate inside a tenant without leaving a log entry, the entire detection model collapses. It’s not a theoretical concern. It’s a practical one, and it’s been exploitable in the wild.
The third bypass, which TrustedSec refers to internally as its third finding in the series, involves authentication through a specific legacy protocol endpoint. The firm’s researchers discovered that certain token acquisition flows — particularly those involving older OAuth configurations — simply don’t generate sign-in log entries in Microsoft Entra ID. The authentication succeeds. A valid token is issued. But the event never appears in the sign-in logs, interactive or non-interactive. TrustedSec reported this to Microsoft in late 2024.
The fourth bypass is arguably more concerning. It involves the use of a specific Microsoft first-party application ID during authentication. By targeting a particular resource and client combination, an attacker can obtain a valid access token that grants access to Azure resources while producing zero log entries. TrustedSec’s researchers confirmed this works against tenants with default logging configurations — which is to say, the vast majority of Azure deployments.
“We are releasing these details because we believe defenders need to understand the limitations of the telemetry they rely on,” TrustedSec wrote in its disclosure. The firm followed a responsible disclosure timeline, notifying Microsoft and waiting what it considered a reasonable period before going public. Microsoft acknowledged the reports but, according to TrustedSec, did not provide a firm timeline for remediation on all findings.
The first two bypasses tell an instructive story about Microsoft’s patching cadence on logging issues. The first bypass, disclosed in September 2024, exploited a gap in how non-interactive sign-ins to certain Microsoft resources were recorded. Microsoft eventually addressed it, but the fix took months to roll out. The second bypass, disclosed in January 2025, targeted a different authentication flow with the same result: successful authentication, no log. That one, too, was eventually patched — partially.
Partial fixes are a recurring theme here. TrustedSec notes that some of Microsoft’s remediations addressed the specific proof-of-concept scenarios the researchers demonstrated but didn’t close the underlying architectural gaps that made the bypasses possible. So researchers kept looking. And they kept finding new paths to the same outcome.
The implications for incident response teams are severe. Consider a scenario where an organization detects suspicious activity — data exfiltration, privilege escalation, lateral movement — and turns to its Azure sign-in logs to identify the initial access point. If the attacker used one of these bypass techniques, the logs will show nothing. No failed attempts. No successful ones. The attacker’s entry point becomes invisible, and the forensic timeline has a hole in it that can’t be filled with standard Microsoft telemetry.
This isn’t an academic exercise. Nation-state actors and sophisticated criminal groups have repeatedly targeted Microsoft’s identity infrastructure. The Storm-0558 campaign in 2023, in which Chinese hackers forged authentication tokens to access U.S. government email accounts, exposed fundamental weaknesses in how Microsoft handles identity and logging. A subsequent review by the Cyber Safety Review Board found that Microsoft’s security culture needed significant reform. Microsoft responded with its Secure Future Initiative, a company-wide effort to prioritize security. But the TrustedSec findings suggest that logging gaps — the kind that make breaches invisible — persist.
Microsoft’s position on logging has itself been a point of contention. Until 2023, detailed sign-in and audit logs were available only to customers paying for premium licensing tiers, specifically Microsoft Entra ID P1 or P2 (or the equivalent E5 security bundle). After the Storm-0558 incident and significant pressure from the U.S. Cybersecurity and Infrastructure Security Agency, Microsoft agreed to make more logging available to lower-tier customers. But “more logging” doesn’t help if the logs themselves have blind spots.
Security researchers on X (formerly Twitter) have been discussing the TrustedSec findings since the disclosure went live, with several noting that the bypasses undermine confidence in Azure’s audit trail as a reliable source of truth. One recurring observation: organizations that rely solely on Microsoft-native logging for their security operations center are operating with an incomplete picture, and these bypasses make that incompleteness exploitable.
TrustedSec recommends several mitigations, though none are perfect. Organizations can supplement Azure sign-in logs with network-level telemetry, capturing authentication traffic at the proxy or firewall layer to create an independent record of connections to Microsoft’s login endpoints. Conditional Access policies can restrict which applications and authentication flows are permitted, potentially blocking some of the specific client-resource combinations these bypasses exploit. And organizations can monitor for token usage — looking at resource access logs rather than sign-in logs to detect activity that shouldn’t be there.
But these are workarounds. The fundamental issue is that Microsoft’s identity platform is generating incomplete audit records for certain authentication paths, and the vendor has not moved quickly enough to close the gaps. TrustedSec’s decision to go to full disclosure reflects a judgment that the risk to defenders from continued ignorance outweighs the risk of giving attackers a roadmap. Given that sophisticated threat actors likely already know about these techniques — or have discovered similar ones independently — that judgment seems sound.
Microsoft did not immediately respond to requests for comment on the latest bypasses. The company has previously stated that it takes all security reports seriously and investigates them thoroughly. Its Secure Future Initiative, announced in late 2023 and expanded in 2024, commits to making security the top priority across all engineering teams. Whether that commitment extends to treating logging completeness as a security-critical feature — rather than a telemetry nice-to-have — remains an open question.
The broader industry context makes these findings especially relevant. Organizations have spent the last several years migrating identity management to the cloud, concentrating authentication authority in platforms like Microsoft Entra ID, Okta, and Google Workspace. That concentration creates efficiency. It also creates single points of failure for detection. When the identity provider’s logs can’t be trusted to record all authentications, every downstream security control that depends on those logs — SIEM correlation rules, automated response playbooks, compliance audit trails — is degraded.
And the problem may not be unique to Microsoft. TrustedSec’s research focused on Azure because of its market dominance, but the underlying issue — that certain authentication flows can slip through logging instrumentation — could theoretically affect any large identity platform with legacy protocol support and complex token issuance paths. No other vendor has faced the same level of public scrutiny on this specific issue, which may say more about research focus than about comparative security posture.
For CISOs and security architects, the takeaway is uncomfortable but clear: sign-in logs are necessary but not sufficient. They are one data source among many, and they have known gaps that sophisticated adversaries can exploit. Building a detection strategy that treats any single log source as authoritative is a structural weakness. Layered telemetry — combining identity logs with network data, endpoint detection, and application-level audit trails — is the only defensible approach when the identity provider’s own instrumentation can’t guarantee completeness.
TrustedSec says it will continue researching Azure authentication flows and expects to find additional bypasses. The firm’s track record — four findings in less than a year, each exploiting a different pathway — suggests that expectation is well-founded. Microsoft, for its part, faces a credibility test. The company has made sweeping promises about security transformation. Logging gaps that render breaches invisible are precisely the kind of issue that will determine whether those promises translate into engineering reality.
Four bypasses. Months of disclosure timelines. Partial fixes. The pattern speaks for itself.
WebProNews is an iEntry Publication