AADSTS76021 fix: SAML request not signed but required

What does AADSTS76021 mean?

Microsoft’s description:

ApplicationRequiresSignedRequests: The request sent by client is not signed while the application requires signed requests

This is a SAML error. Microsoft’s troubleshooting article says it “indicates that the client didn’t sign the request, but the application requires signed requests. Even if the client signs the request, the signature might not be added according to the SAML binding configuration.”

The requirement comes from a setting on the enterprise app. Microsoft: “To enable the verification of signed requests, select Require verification certificates and upload a verification public key that matches with the private key used to sign the request.” Once that is on, Entra ID rejects an AuthnRequest it can’t verify. Microsoft’s list of verification failures includes “Request not signed, but verification is enabled.”

Where the signature goes depends on the binding:

• HTTP-Redirect: “the signature is included as a query parameter in the URL” (SigAlg and Signature).
• HTTP-POST: “the signature is embedded within the XML payload of the SAML message.”

“If the application expects the signature in one location but the request uses another binding type, Microsoft Entra ID rejects the request.”

Is it an attack?

No. The setting exists so Entra ID only accepts requests the real service provider signed. 76021 is that check refusing a request. Microsoft also notes that “Requestor verification is provided for by only responding to registered Assertion Consumer Service URLs”, so an unsigned request can’t send the response somewhere new.

Pattern	Likely meaning
Every user of one SAML app fails, starting at a known change	Someone enabled Require verification certificates and the app doesn’t sign its requests.
Failures began when the app or its proxy was updated	The app now signs with a different key, or uses a different binding.
Users fail when they open the app from My Apps or the Microsoft 365 app launcher	Microsoft says the setting “will not allow IDP-initiated authentication requests (like SSO testing feature, MyApps or M365 app launcher) to be validated.” Microsoft doesn’t say which error code users see then. Our reading: 76021 is a likely candidate.

Users report it in exactly this shape. In a Microsoft Q&A thread, sign-in worked until the signature verification feature was turned on, then failed with 76021. The moderator’s two causes: the app doesn’t send a signed request, or the wrong certificate is uploaded.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 76021 lands in. Check your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "76021"
| summarize Rows = count(), Apps = dcount(AppId) by SourceTable

Which apps fail, for how many users, and since when. The first failure time tells you when to look in the audit log:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "76021"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            Protocols = make_set(AuthenticationProtocol, 5)
          by AppDisplayName, AppId
| sort by Users desc

Who changed the app shortly before the failures began. Microsoft lists Update service principal as an audit activity. Our assumption: turning on verification certificates is recorded under it; Microsoft doesn’t say so. Set the time window around FirstSeen:

AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "ApplicationManagement"
| where OperationName == "Update service principal"
| extend App = tostring(TargetResources[0].displayName),
         ByUser = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, App, ByUser, Result
| sort by TimeGenerated desc

ResultType is a string column, so compare it with "76021".

How do I fix AADSTS76021?

For the user: you can’t fix this. Tell your IT team which app failed and when. If you opened it from My Apps, also try the app’s own sign-in page, since requests started from the portal can’t be validated with this setting on.

For the app owner or vendor (service provider):

1. Sign every SAML AuthnRequest with the private key that matches the certificate uploaded in Entra ID.
2. Use RSA-SHA256. Microsoft: “Only RSA-SHA256 is supported”, with an admin opt-in for RSA-SHA1.
3. Put the signature where the binding expects it. For HTTP-Redirect it must be in the query string. For HTTP-POST it must be inside the XML <Signature> element.

For admins:

1. Go to Entra ID > Enterprise apps > All applications > the app > Single sign-on > SAML Certificates > Verification certificates > Edit. Check that the uploaded certificate is the one the app signs with and hasn’t expired.
2. Check the binding the app uses (HTTP-Redirect or HTTP-POST) matches its SAML configuration, as Microsoft’s troubleshooting article says.
3. If the app can’t sign requests, clearing Require verification certificates removes the requirement. That turns off the protection, so do it only as a deliberate decision.
4. The SSO test button in the admin center doesn’t work with this setting on. Microsoft: “the test experience is disabled as the service provider has to sign the request.” Test from the app’s own sign-in page instead.