Troubleshoot corporate SSO sign-in: correct email, device registration, and when to contact IT

Use this guide to identify a corporate single sign-on (SSO) error, check the account email, and decide whether your dealership administrator, corporate IT team, or myKaarma Support should act next.

Overview

With SSO, myKaarma redirects you to your organization's identity provider, such as Okta, Azure, or Duo. Errors on an organization-branded page usually require corporate IT to review the account, app assignment, device, or access policy.

Identify the sign-in method

What you see	Sign-in method	Owner
An organization-branded page, Okta prompt, Microsoft prompt, or identity-provider error	Corporate SSO	Corporate IT first
A myKaarma page asking for a code after you enter your email and password	myKaarma MFA	You or an authorized dealership administrator
A myKaarma login page with Reset Password	Local myKaarma password	You or an authorized dealership administrator

Important: Resetting a myKaarma password does not correct a corporate SSO error.

Visual Examples

Below are examples of Corporate SSO pages with an error message.
*Please note, the visual details for the Corporate SSO page can vary by dealer group or dealer.

Below is an example of a myKaarma MFA page.

Below is an example of a myKaarma login page, with a "Reset Password" link.

Troubleshoot Corporate SSO

Record the exact error message and the page where it appears. Include a screenshot and redact any sensitive details or tenant identifiers in the screenshot.
Confirm which email address is stored on your myKaarma user account.
Ask corporate IT to compare that address with the corporate identity used for SSO.
If the identity provider says the user is not assigned, ask corporate IT to assign the user to the myKaarma enterprise application.
If the message refers to device registration, browser requirements, or conditional access, ask corporate IT to complete the required organization-owned setup.
Retry sign-in after corporate IT confirms the account, application assignment, and device requirements.

An authorized dealership administrator can review a user's myKaarma details under Settings » Users » Manage Users (depicted below). Corporate IT controls identity-provider assignments, organization access policies, and device registration.

When Desktop works but mobile does not

A mobile or new-device failure can come from an organization policy even when Desktop access works. Share the device type, browser or app, exact message, and whether Desktop sign-in succeeds with corporate IT. Follow the organization's approved browser and device-registration instructions.

Who should take the next action

Owner	Actions
End user	Record the error, confirm the email used, retry after the assigned owner completes the change, and remove account details from screenshots.
Dealership myKaarma administrator	Review the myKaarma user record, confirm that the account is active, and correct supported user details.
Corporate IT or identity team	Confirm the corporate identity, assign the user to the enterprise application, and resolve organization-owned access or device policies.
myKaarma Support	Investigate when corporate authentication succeeds but myKaarma rejects the account, a verified user change is not reflected, or multiple users have the same unexplained post-SSO failure.

Information to collect

Record the exact error message and the page where it appears. Include a screenshot and redact any sensitive details or tenant identifiers in the screenshot.
Whether the error appears on a myKaarma page or an organization-branded page.
Account email used for myKaarma and the corporate sign-in.
Device type and access method: Dealer App in an internet browser or the Desktop App or Mobile App.
Test: Whether you were able to log in on another user's device.
Scope: Whether one, multiple, or all users are affected.

For corporate IT teams

myKaarma supports corporate SSO integrations, including Okta, Azure, Duo, and other options available upon request. Contact myKaarma Support for current supported-provider requirements and secure configuration documentation. Do not send SSO metadata, certificates, secrets, or tenant identifiers through a public support article or unsecured message.