Checkmarx Login: SSO, SAML, and Secure Access Explained

The Checkmarx login is best handled through SAML single sign-on rather than standalone local accounts, because SSO centralizes authentication, enforces your identity provider's MFA policy, and removes a separate password store from a system that holds sensitive source-code findings. If you are setting up access to Checkmarx One or an older CxSAST deployment, the login flow you choose shapes both day-to-day developer experience and your audit posture.

This guide walks through how the Checkmarx login actually works across surfaces, what SAML gives you, and the access-hardening decisions worth making before you roll it out to a team.

Where the Checkmarx login happens

Checkmarx is not a single screen. Depending on which product and version you run, developers authenticate from several places:

• The Checkmarx One web console (the SaaS platform).
• The legacy CxSAST web interface for on-premise deployments.
• IDE plugins for Visual Studio Code, IntelliJ, Eclipse, and Visual Studio.
• The CLI and CI integrations, which usually authenticate with an API key or OAuth client credentials rather than an interactive login.

Each of these can be pointed at the same identity provider, which is the whole reason SSO matters. A developer who has authenticated once in the browser can, in most configurations, reuse that session when they trigger a scan from their editor. The VS Code and JetBrains plugins support login via SSO, so you are not asking engineers to paste passwords into a plugin settings pane.

Why SAML single sign-on is the sensible default

SAML (Security Assertion Markup Language) is an open standard that lets an identity provider pass authentication and authorization assertions to a service provider, so the user never hands credentials directly to the downstream application. For a code-security tool, that separation is valuable. The findings Checkmarx stores are effectively a map of your weakest code paths, and you do not want that behind a password that lives only in the scanner's own user table.

Checkmarx One supports SAML-based SSO with the common enterprise identity providers, including Azure Active Directory (now Entra ID) and Okta. The setup follows the standard SAML dance: you register Checkmarx as a service provider in your IdP, exchange metadata, and map SAML attributes to Checkmarx roles. That attribute-to-role mapping is the part teams under-use. Rather than assigning roles by hand inside Checkmarx, you can drive them from an IdP group claim, so a change in your directory propagates automatically.

The login itself then works one of two ways. A user can go to the Checkmarx login page and click the identity-provider button, which redirects them to the IdP for authentication. Or they launch from a Checkmarx tile on their IdP dashboard, which starts the flow from the IdP side. Both land in the same authenticated session.

Setting up the login flow without locking yourself out

The most common self-inflicted incident during SSO rollout is losing administrative access. When you flip a tenant to SAML-only, an admin whose account is not correctly mapped in the IdP can be locked out of the very console they need to fix the mapping.

Two precautions handle this:

1. Keep at least one break-glass local administrator account with a long, vaulted password and MFA, exempt from the SSO-only enforcement, until you have verified the SAML flow end to end with a real non-admin user.
2. Test the attribute-to-role mapping with a throwaway test user before you migrate the whole team. Confirm that the SAML assertion actually delivers the group claim you expect. IdP admin consoles frequently send a claim name that differs from what the documentation assumes.

Once a normal user can log in and lands with the correct role, retire the reliance on local accounts.

Hardening the accounts behind the login

SSO moves the security question up a layer: your Checkmarx posture is now only as strong as the identity provider session behind it. That is a good trade, but it means the hardening work happens in the IdP.

• Enforce phishing-resistant MFA on the IdP group that can reach Checkmarx. A scanner console is a high-value target because it reveals exploitable weaknesses.
• Scope sessions sensibly. Long-lived sessions are convenient but raise the blast radius of a stolen laptop. A session lifetime in the range of a normal work shift is a reasonable balance.
• Separate the interactive login from automation. CI pipelines and the CLI should authenticate with dedicated service credentials or OAuth clients, each scoped to the minimum needed, and rotated. Never reuse a human's SSO session for a build agent.

Treat API keys as their own risk class. A Checkmarx API token that leaks into a build log or a committed .env file grants programmatic access that bypasses the interactive login entirely. Scanning your own repositories for leaked scanner credentials is a worthwhile exercise, and an SCA and secrets-aware tool such as Safeguard can flag committed tokens before they reach a shared branch. If you want the broader picture of how source-code exposure feeds into supply chain risk, our write-up on choosing an SCA solution covers the adjacent tooling.

Common Checkmarx login problems and what causes them

A handful of failure modes account for most login tickets:

• Redirect loop between Checkmarx and the IdP. Usually a clock-skew or a mismatched Assertion Consumer Service URL. Confirm the SP metadata URL registered in the IdP exactly matches the tenant.
• Authenticated but no permissions. The SAML assertion succeeded but the role claim did not map. Inspect the raw SAML response (browser dev tools or a SAML tracer extension) and compare the attribute name against the mapping.
• IDE plugin cannot complete SSO. Older plugin versions handle the browser handoff differently. Update the plugin, and make sure the machine can open the system browser for the OAuth/SAML redirect.
• Cannot read property style null errors in a plugin. Almost always a version mismatch between the plugin and the server, not an auth fault. Align versions first.

FAQ

Can I use Checkmarx without SSO?

Yes. Local accounts work, and small teams or evaluation environments often start there. But for any shared production deployment, SAML single sign-on through your identity provider is the recommended login path because it centralizes MFA, session policy, and deprovisioning.

Does the Checkmarx login support MFA directly?

Checkmarx itself defers multi-factor authentication to your identity provider under SSO. You enforce MFA in Azure Entra ID, Okta, or whichever IdP you federate with, and Checkmarx honors the authenticated assertion.

How do CI pipelines authenticate if humans log in with SSO?

Pipelines should not use interactive SSO. They authenticate with API keys or OAuth client credentials scoped to a service identity, kept in your CI secrets store and rotated on a schedule, separate from any human login.

What is the difference between the Checkmarx One login and CxSAST login?

Checkmarx One is the newer SaaS platform with a unified console; CxSAST is the older on-premise SAST product with its own web interface. Both support SAML SSO, but the setup screens and supported IdP integrations differ by version, so follow the docs for the product you actually run.