Hosted MCP Logins W/ SSO Failing

What to do

• Check whether you use Harness Platform, Platform, Platform, Platform and 1 more. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 2h 38m it lasted.

  Anything that failed between 2026-10-05 22:01 UTC and 2026-10-06 00:39 UTC may need a replay.

• Subscribe to Harness's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=harness works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from Harness 6

1. investigatingOct 5, 2026, 10:01 PM UTC

   We are currently investigating this issue.

   provider

2. identifiedOct 5, 2026, 11:50 PM UTC

   The issue has been identified and a fix is being implemented.

   provider

3. monitoringOct 6, 2026, 12:26 AM UTC

   A fix has been implemented and we are monitoring the results.

   provider

4. monitoringOct 6, 2026, 12:26 AM UTC

   We are continuing to monitor for any further issues.

   provider

5. resolvedOct 6, 2026, 12:39 AM UTC

   Verified the fix and resolved SSO issues.

   provider

6. postmortemOct 9, 2026, 4:17 PM UTC

   ## Okta Application SP-Initiated SSO Login Failures ‌ # Summary ‌ Between October 5, 2026, 18:18 UTC and October 6, 2026, 00:26 UTC, some Harness customers were unable to sign in to the Harness Hosted MCP server via SAML Single Sign-On \(SSO\). The main Harness Portal user authentication remained fully operational. Affected users saw login errors or were redirected to an invalid SSO page instead of completing sign-in. ‌ The issue was caused by breaking changes in a version upgrade of the Harness identity service HarnessID. We fixed it with a series of hotfixes, and SSO login was fully restored for all affected customers. ‌ # Impact ‌ Users signing in to Harness MCP via SAML SSO were unable to complete authentication. Existing MCP sessions that relied on SSO could not be refreshed, so some users had to sign in again and could not. Non-SSO logins to Hosted MCP worked during most of the incident. No customer data was lost or exposed. Customers using their own generic SAML 2.0 application configuration in Okta were not affected. # Root Cause On September 29, 2026, an updated version of the Harness application was published to the Okta Integration Network. The update added support for registering multiple reply \(ACS\) URLs, so that customers running Harness across several regions or environments could configure more than one callback URL. ‌ Harness includes an AssertionConsumerServiceURL value in the SAML authentication request it sends to Okta. Before this update, Okta did not validate that value for application instances without additional ACS URLs configured and instead returned the SAML assertion to the application's default ACS URL. After the update, this validation became active across all existing application instances, including those where the customer had never configured an additional ACS URL. Because the requested value was not present in the instance's registered list, Okta returned an HTTP 400 error. ‌ The updated application went through Okta's standard OIN publishing review, which includes backward-compatibility verification against existing installations of the published integration. This change in validation behavior for instances with no additional ACS URLs configured was not surfaced during that review, so it reached customers at the time of release. # Remediation **Immediate Response** ‌ Two workarounds were published on the status page: sign in from the Harness tile in Okta \(IdP-initiated login\), which was unaffected, or register the application's Okta SSO URL in the Additional ACS URLs field of the Harness Okta application. Harness engaged each reported affected customer directly and validated their sign-in. ‌ **Resolution** ‌ Rolling the application back to the previous version was deliberately avoided, as that would only defer the same disruption to the next release. Every affected customer was instead unblocked through the ACS URL registration, and we are working with Okta to make the ACS URL validation conditional again, so that instances with no additional ACS URLs configured behave exactly as they did before, and no customer action is required. # Action Items To prevent such issues from happening again, Harness will take the following action items ‌ 1. Working with Okta to restore conditional ACS URL validation, so instances with no additional ACS URLs configured behave exactly as before and no customer action is required. 2. Publish a dedicated configuration guide for the Harness OIN application in Harness documentation, including reply \(ACS\) URL requirements. 3. Add an independent pre-release verification step against existing customer configurations for any future update to the published Okta application, alongside Okta's own review. 4. Migrate user authentication to Harness ID, which removes the dependency on this validation behavior entirely.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.