Getting Into Tradeshift When Everything Is Pushed to MFA and SSO
The Tradeshift platform moved hard toward multi-factor authentication and SAML-based single sign-on somewhere around late 2023, and the 2024 rollout tightened things even further. If you are trying to work through a Tradeshift Login 2024 Secure Access Features Troubleshooting Guide, you are probably already past the point of just typing a password and hoping for the best. The login flow now involves device binding, push verification, and in many organizations, a corporate identity provider that controls session lifetime independently of Tradeshift itself. That means failures happen at several different layers, and the error messages rarely tell you which layer actually rejected the request. Under the older setup, most login problems came from expired cookies, stale SSO tokens, or a password that someone changed without updating their saved credentials. The 2024 iteration added a device trust policy, adaptive risk scoring on each login attempt, and stricter CORS behavior for the API endpoints that the login redirect depends on. Combined with SSO providers that enforce shorter session windows, you can get redirected to an authentication error page even when your credentials are completely valid. I ran into a case where a buyer team could not reach their invoice queue for about three days. The error was a blank white page after the SSO redirect, no exception details, just a stuck state. What actually happened is that the company had recently migrated from Azure AD to Okta as their SAML provider, but the Tradeshift tenant still had the old metadata URL cached. The redirect worked, Okta issued a token, Tradeshift accepted it, and then the session validation failed silently because the entity ID did not match the re-registered account profile. The fix was not on the user side at all. It required an admin to update the SAML configuration under the tenant settings and flush the cached assertion consumer service URL. That took about twenty minutes once someone actually knew where the setting lived.
The Core Components of the Tradeshift 2024 Login Flow
Understanding the flow helps when something breaks, because the troubleshooting path changes depending on which component is failing. The current process works like this: you navigate to the Tradeshift portal, the system detects whether your organization uses direct credentials or SSO, you are redirected to the corporate identity provider if applicable, you complete any required MFA challenge, the provider sends a SAML assertion back, Tradeshift validates the assertion, binds the session to your device fingerprint, and then loads your workspace. Each of those steps has its own failure mode. The SSO redirect can fail because of a misconfigured redirect URI, an expired certificate on the identity provider side, or a corporate firewall blocking the SAML metadata endpoint. The MFA step can fail because your authenticator app clock is out of sync, your registered phone number changed, or your organization disabled your MFA factor during a security sweep. The assertion validation can fail because the SAML response contains attributes that do not match your Tradeshift account mapping, the email or employee ID field is missing, or the issuer statement does not line up with the trusted list on the tenant.
Password-Only Login Issues
Even with SSO widespread, some tenants still operate a password-based entry path for external suppliers who have not completed corporate onboarding. Those logins are hitting rate limits more often now. The platform enforces a lockout policy that triggers after five failed attempts within fifteen minutes, and the lockout duration scales up to an hour on repeated violations. If you are seeing a message about too many attempts when you know your password is correct, do not keep typing it. Wait out the window, then try again. More importantly, check whether a shared terminal, a password manager running auto-fill, or a mobile keyboard cache is submitting an outdated credential in the background. Another subtle issue with password login in 2024 is the password history enforcement combined with bulk password resets. When an admin pushes a temporary password to a group of suppliers, those temporary passwords are sometimes rejected immediately because the reset script copies the old password hash status incorrectly from the migration batch. I saw this happen with a vendor onboarding team that imported three hundred accounts at once. The first forty logins succeeded, the next hundred got password invalid errors, and the remaining accounts were fine. The root cause was a pagination bug in the reset endpoint that did not clear the forbidden-password flag for batches processed after the first chunk. The workaround was to trigger individual password resets for the affected accounts rather than re-running the bulk job.
Get the Full Details
MFA and Push Verification Troubleshooting
The primary MFA method in the 2024 release is a push notification to the Tradeshift mobile app, backed by TOTP as a fallback. Push failures show up in two main flavors: the notification never arrives, or the user approves it and the session still fails to create. When the push does not arrive, the first thing to verify is whether the mobile app is actually registered to the same account you are logging into. A lot of people have personal and professional Tradeshift accounts that share the same email address but different internal IDs. The app registration binds to the internal ID, not the email, so approving a push on the wrong account does nothing for the login session. Check the app dashboard under My Devices to confirm the binding matches the tenant you are targeting. If the push arrives, the approval succeeds, but the web session still errors out, the problem is usually the device binding policy. Tradeshift 2024 tracks device trust through a combination of browser fingerprinting and a stored device token. If you are logging in from a machine that previously had the browser cache wiped, or from a virtual desktop environment, the fingerprint can diverge enough to trigger a secondary verification step that the SSO redirect does not handle gracefully. In those cases, the login loop ends with a device verification timeout. The practical fix is to use the Tradeshift mobile app to scan the device verification QR code on the login screen, which completes the binding handshake faster than waiting for the automatic retry cycle. This usually resolves the stuck state in under two minutes.
TOTP Fallback Problems
TOTP fallback is available but disabled by default on most enterprise tenants. If your organization has enabled it, you might still run into issues when the time synchronization between your device and the Tradeshift auth server drifts. The allowed skew window is only thirty seconds on either side, which sounds generous but can be exceeded if your phone has been in airplane mode for an extended period or if the authenticator app refreshes its counter slowly. Try entering the code within ten seconds of it appearing on the app screen rather than waiting until the last second of the window. Also make sure your authenticator app is set to auto-sync time through network NTP rather than manual entry, because manually adjusted times create permanent drift. SSO failures account for the majority of login tickets in the 2024 release, and they are also the hardest to diagnose without access to the tenant admin console. The common failure points fall into four buckets: metadata mismatches, attribute mapping gaps, certificate expiration, and redirect URI restrictions. Metadata mismatches happen when the SAML provider publishes a new endpoint URL but the Tradeshift tenant still references the old one, or vice versa. The error you usually see is a SAML assertion validation failure with no clear cause. Check the EntityID in your SAML metadata against what is configured in Tradeshift under Admin Console > Identity Providers. If they do not match exactly, update the tenant side to reflect the current provider URL.
Attribute mapping gaps are a frequent silent failure source. Tradeshift expects at minimum an email attribute and usually an employee ID or unique identifier from the SAML response. If your identity provider sends a DisplayName instead of an email, or if the identifier field uses a different namespace, the assertion validates but the account lookup fails. The result looks like an authentication error even though the SSO token itself is fine. The fix is to adjust the attribute mapping on the identity provider side to emit the fields Tradeshift expects, or to update the Tradeshift account linkage under the user profile to match the attributes you are already sending. Certificate expiration is easier to miss because it does not produce a warning before it breaks things. The SAML signing certificate rotates on a schedule defined by your identity provider, and Tradeshift stores the public certificate reference locally. When the provider rotates but the tenant metadata is not updated, every login attempt after the rotation date fails immediately. Check the certificate validity dates in both places if your team recently upgraded or migrated the identity provider. Redirect URI restrictions usually surface when someone changes the corporate SSO domain or adds a subdomain for a regional office without updating the approved redirect list. Tradeshift validates the post-authentication redirect against a whitelist. If the URL does not match an approved entry, the platform returns a generic access denied page. The whitelist lives in the same Identity Provider configuration area, and it must include both the base domain and any regional subdomains your users might hit.
A Real SSO Edge Case I Encountered
One morning a procurement team logged in and found that their purchase orders were visible but they could not submit any new ones. The error only appeared after clicking Submit, not during login, but it was part of the same secure access layer. The issue turned out to be a session scope mismatch caused by a recent SSO policy change. The identity provider had switched from per-application session management to per-tenant session management, which shortened the active session token lifetime from eight hours to two hours. Users who had been logged in for more than two hours appeared authenticated but had lost their write permissions implicitly because the platform treats extended read-only sessions as a security risk under the new policy. The fix was to schedule a mass re-authentication during a maintenance window and update the SSO session policy on the provider side to allow longer trusted sessions for internal corporate networks. That resolved the submit errors for everyone within thirty minutes. Even when the backend authentication is working correctly, the client side can block access. Tradeshift 2024 enforces HTTPS-only connections, requires certain cookie attributes, and checks the browser User-Agent against known automation patterns. Corporate proxy servers and ad blockers are also frequent culprits. The HTTPS requirement means that any bookmark or link using HTTP will be redirected, and some older internal directories still use HTTP. If a user clicks a legacy link, the redirect can drop the SAML assertion parameter during the scheme change, resulting in a login page with no context. Tell users to bookmark the HTTPS version directly and have IT update any internal link catalogs.
Cookie attributes matter because Tradeshift sets Secure, SameSite=None, and HttpOnly flags on its session cookies. Browsers that do not support these flags or that block third-party cookies by default will fail to maintain the session across the SSO redirect. Safari in private browsing mode, some corporate-managed Chrome profiles, and older versions of Edge have all shown this behavior. The workaround is to use a standard browsing profile with third-party cookies enabled for the Tradeshift domain, or to add an exception in the browser cookie settings. Ad blockers and privacy extensions can strip query parameters from the redirect URL, which includes the SAML request ID and the return URL. If the parameters are removed, Tradeshift cannot complete the authentication handshake. The quickest test is to open the login page in incognito or private mode with all extensions disabled. If login works there, re-enable extensions one by one to identify the culprit, then add Tradeshift to that extension's allow list.
What the Tradeshift Login 2024 Secure Access Features Troubleshooting Guide Should Cover
If you are building or following a guide for this platform, the most useful structure addresses the failure layers in order of probability, not in order of complexity. Start with the client-side checks because they account for a surprising number of reported failures, then move to MFA and device binding, then SSO and attribute mapping, and only then consider tenant-level configuration issues. Include a decision tree that asks the user to identify whether the failure happens before, during, or after the SSO redirect. That single question eliminates half the possible causes immediately. A failure before redirect is almost always a credential or account status issue. A failure during redirect points to SSO configuration. A failure after redirect but before the workspace loads usually indicates a device trust or session binding problem. Also document the error codes that Tradeshift actually returns. The platform surfaces a small set of standardized codes for common failures, but the UI does not always display them. Having users enable developer tools and capture the network response gives you the exact error code in under a minute, which is far more reliable than guessing based on the screen text.
Known Limitations and When to Escalate
Some problems simply cannot be resolved at the user level. Tenant-wide SAML misconfigurations require admin access. Account linkage issues between SSO and direct credentials need support intervention. Bulk password reset bugs, like the pagination issue I described, require a platform patch. If you have worked through the client checks, verified MFA registration, confirmed the SSO metadata matches, and the login still fails, the next step is opening a support ticket with the network response details and the time of the failure. Including a screenshot of the device binding status from the mobile app also helps, because the support team can cross-reference the device fingerprint against the session logs. The 2024 secure access features are solid overall, but they are sensitive to changes in the surrounding identity infrastructure. The more moving parts you have between the user browser and the Tradeshift server, the more places something can drift out of alignment. Keeping your SAML metadata current, your device registrations accurate, and your browser settings aligned with the platform requirements covers the vast majority of issues without needing to dig into the deeper configuration layers.
