There are cases where the instance will generate two SAMLRequests like the following example from the logs:

13:25:40.687 Info Default-thread-217 39C6B82B13B41A008799BDA12244B0ED *** Script: SAML Request xml: AssertionConsumerServiceURL="https://cengageqa.service-now.com/navpage.do"
Destination="https://sts.cengage.com/adfs/ls/" ForceAuthn="false"
ID="SNCba82f60ab03bb2434969233d9088d611" IsPassive="false"
IssueInstant="2016-01-12T21:25:40.673Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
ProviderName="https://cengageqa.service-now.com/navpage.do" Version="2.0">https://cengageqa.service-now.com
13:25:40.765 Info Default-thread-217 39C6B82B13B41A008799BDA12244B0ED *** Script: SAML Request xml: AssertionConsumerServiceURL="https://cengageqa.service-now.com/navpage.do"
Destination="https://sts.cengage.com/adfs/ls/" ForceAuthn="false"
ID="SNCe2ea5b24ffafe346357625c534776af1" IsPassive="false"
IssueInstant="2016-01-12T21:25:40.750Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
ProviderName="https://cengageqa.service-now.com/navpage.do" Version="2.0">https://cengageqa.service-now.comFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>

The login requests are for the same session and note the timestamps. The SAMLResponse includes the following error:

13:25:40.956 Error Default-thread-221 39C6B82B13B41A008799BDA12244B0ED SEVERE *** ERROR *** SAML2: SAML2ValidationError: InResponseTo attribute in SubjectConfirmationData mismatch.

We stored the second ID "SNCe2ea5b24ffafe346357625c534776af1" but we get the SAMLResponse of the first, ""SNCba82f60ab03bb2434969233d9088d611"

There is no known workaround for this issue. To receive notifications when more information is available, subscribe to this Known Error article by clicking the Subscribe button at the top right of the article. If you are able to upgrade, review the Fixed In field to determine whether any versions have a permanent fix.