Does Your TMS Need SSO for NIS2 Compliance?

Yes, most likely. If your company is in scope for NIS2 as an essential or important entity, your TMS needs multi-factor authentication "where appropriate," and SSO/SAML is the practical way admins deliver that without juggling separate passwords for every carrier module. If you're technically out of scope, turn it on anyway. It's the cheapest fix for the shared-login habits that build up in any TMS over a few years.

Is transport and logistics actually in scope for NIS2?

Yes, for most manufacturers and retailers running their own logistics operation or acting as a logistics service provider. Transport and logistics is explicitly listed as one of the critical sectors covered by NIS2, including road carriers, rail operators, airports and port authorities, inland waterway transport companies, and logistics service providers.

Size matters here. Companies meeting the size threshold of 50+ employees or over 10 million euros in revenue are in scope. Within that, there's a split between the two classifications: large companies with 250+ employees in Annex I sectors are classified as essential entities, while those with 50 to 249 employees are important entities with reactive supervision. Both classifications carry the same substantive obligations, so don't spend time trying to argue your way into the lighter category. If you're the sole operator of a facility that others depend on, size thresholds may not even save you: if a small company is the sole provider of a service that is critical to national infrastructure, it may still fall within scope.

Does turning on SSO by itself satisfy the NIS2 MFA requirement?

No. SSO centralizes login. MFA verifies identity. You need both configured together at your identity provider, because logging in once with a single password (even through a slick SSO portal) is not the same as proving you are who you say you are.

The legal text is specific but leaves room for judgment. The relevant NIS2 article requires the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems within the entity, where appropriate. That phrase "where appropriate" isn't a loophole. It means wherever there is a likelihood that the lack of MFA protection could result in a cyber breach, and entities should be able to show they've assessed their identity attack surface and mitigated the risk accordingly. For a TMS admin, that assessment is straightforward: dispatcher logins, carrier API credentials, and any account with rate-editing or label-generation rights all count as high-risk access.

On the technology side, plain SMS codes are increasingly seen as the bare minimum rather than best practice. Current guidance treats phishing-resistant authentication as the state of the art for high-risk access classes: FIDO2/WebAuthn security keys, platform authenticators with attestation, and passkeys synchronised through provider-attested clouds. If you're buying hardware keys for your top 10 TMS admin accounts this year, you're not overreacting.

What's the practical difference between SSO and MFA for a TMS admin?

SSO removes per-system passwords. MFA adds a second proof of identity at login. You configure both once at your identity provider (Entra ID, Okta, OneLogin), not inside the TMS itself — the TMS just needs to trust that provider's assertions.

The plumbing is SAML: your identity provider is the source of trust, and the TMS is the "service provider" that accepts a signed assertion instead of a password. The SAML standard defines how an identity provider and a service provider communicate using XML markup, allowing different services to exchange authentication and authorization data to implement single sign-on.

Here's where most go-lives actually stall, and it's rarely the concept — it's a typo. The two fields that cause almost every failed cutover are:

• The Entity ID (Identifier). The Entity ID configured in the identity provider must exactly match what the application expects, and even a trailing slash can cause a mismatch.
• The Reply URL / ACS URL. If the Reply URL doesn't match the ACS URL the application expects, authentication will fail, so verify the URL is exact, including the protocol and path.
• User assignment. Even with a perfect config, nobody logs in if the security group hasn't been assigned to the enterprise application — a step that catches a surprising number of admins on their first rollout.

Print those three checks and keep them next to your rollout runbook. Nine times out of ten, a "SSO is broken" ticket is one of these.

Which TMS platforms actually support SSO/SAML today?

Most enterprise suites ship it natively. Mid-market and multi-carrier tools vary a lot more, so check before you promise a go-live date to your ops director.

Before you commit to a rollout date, check your identity provider's app gallery for a pre-built connector — it saves you the manual metadata exchange entirely for well-known platforms.

How do you roll out SSO without locking dispatchers out mid-shift?

Stage it. Pilot with admins first, keep a break-glass local login active for two weeks, and cut over role by role rather than company-wide in one weekend.

A rollout sequence that holds up under real shift patterns:

1. Pilot with 3-5 admin accounts for one week, testing both SP-initiated and IdP-initiated login flows.
2. Keep one break-glass local account per shift active and documented, tested weekly, not just created and forgotten.
3. Cut over by role group: dispatch day shift, then night shift, then customer service, then finance/rating users last since they touch the most sensitive screens.
4. Set a hard password-login sunset date, communicated at least two weeks ahead, with a fallback contact for anyone locked out.

If you've already built a credential rotation runbook for your TMS, reuse the same hypercare structure here — the failure modes (forgotten break-glass tests, no fallback contact) are nearly identical. For the technical setup steps, Microsoft's own guide to enabling SSO for an enterprise application is a solid reference to hand your identity team.

What should you check three months after go-live?

Audit for orphaned local accounts, confirm your identity provider's logs actually cover TMS access events, and re-test your break-glass account. This is the same recovery documentation an NIS2 assessor will ask to see.

Documentation matters as much as the technical control here. Meeting the NIS2 MFA requirement means more than switching on multi-factor authentication — it means assessing where MFA is needed, deploying phishing-resistant factors on high-risk access, and documenting all of it for a supervisory authority and your own board. If an auditor asks where MFA is enforced, "everywhere" is not an acceptable answer. You need a list of access classes, and the list itself becomes your audit artefact.

One caution worth repeating: SSO and MFA don't replace role and permission hygiene. A dispatcher with admin-level rating access is still a risk, phishing-resistant login or not. Pair this rollout with a proper review of who has what access inside your TMS, not just how they log in.