SSO, SCIM, and the leaver problem
Single sign-on is usually sold on convenience. The convenience is real and it is not the point — the point is that when somebody leaves, they actually lose access.
What is supported
SAML 2.0 and OpenID Connect against any compliant identity provider — Entra ID, Okta, Google, Ping, JumpCloud and the rest. There is no per-provider integration to buy and no tier that withholds it, because an authentication mechanism sold as an upgrade is a security control sold as an upgrade.
SCIM 2.0 for provisioning, which is the half that people skip and then regret. SSO governs how somebody authenticates; SCIM governs whether an account exists at all, and the difference matters most on the day somebody leaves.
Group-to-role mapping, so access follows the groups your identity provider already maintains. A person added to a programme's group receives the corresponding role here, and the mapping is configuration an administrator can read rather than a synchronisation script.
Why deprovisioning is the whole argument
With SSO alone, a leaver's account still exists in Manufacturing PLM. They cannot authenticate through the identity provider, which sounds sufficient and is not, for two reasons that both show up at audits.
The account remains a valid grantee. It holds roles, appears in approver lists, may be a workflow's designated approver, and can hold assigned tasks that nobody is going to action. A workflow routing to a departed person's account stalls silently, which is a common and genuinely maddening failure.
And a local credential may still work. Any account with a password set before SSO was enabled, or any API token issued to that user, is a path that the identity provider does not govern. Manufacturing PLM handles this by disabling local authentication entirely once SSO is enforced, and by tying API tokens to the account's active state rather than to their own expiry alone.
With SCIM, deactivation in your identity provider deactivates the account here, reassigns nothing automatically, and surfaces what that person held — open tasks, approver roles, owned objects — as a list somebody has to act on. The system will not quietly redistribute a departed person's responsibilities, because a silent reassignment is how an approval ends up with somebody who does not know they own it.
The failure it prevents
A contractor finishes an engagement. Their identity provider account is disabled the same day, correctly and promptly.
Four months later, an integration built during the engagement is still running against an API token issued under their account. It has write access to item data. Nobody knows it exists, because the person who built it is gone and the token does not appear in any leaver checklist.
The account was disabled and the access was not. Tokens tied to account state rather than to their own expiry close this the moment the account deactivates, and the token appearing in the leaver's held-items list means somebody sees it rather than discovering it during an audit.
How it meets the rest of the product
Roles and permissions are enforced at the data layer regardless of how somebody authenticated, so SSO changes who gets in rather than what they can see once inside. The two concerns stay separate, which is why an identity provider misconfiguration cannot widen anybody's data access.
Where a workflow requires re-authentication for a signature, the re-authentication goes through your identity provider — which means your conditional access policies, device posture rules and MFA requirements apply to it. Manufacturing PLM deliberately does not implement a second password beside your IdP, because that would create a credential your security team cannot govern.
Every authentication event, provisioning change and role assignment lands in the audit trail with its source. At an audit, *how do you know this person had this access on that date* is answered from records rather than from a current-state screen that says nothing about history.
How it meets your ERP
Most organisations run one identity provider across both systems, which makes the pairing straightforward and creates one worthwhile discipline: the same person should be the same identity in both, so that an action attributed here and a transaction attributed there can be tied together.
That matters for reconciliation. When a published value and an ERP value disagree, knowing who last touched each side is materially faster when both systems name the same person the same way.
Manufacturing PLM does not federate to your ERP or act as an identity provider for it. Both systems are relying parties on your IdP, which is the arrangement that survives either of them being replaced.
Where the boundary is
Manufacturing PLM is not an identity provider. It does not manage credentials, offer directory services or act as an authentication source for other systems. It consumes identity and enforces authorisation.
It also does not reassign a departed person's work automatically. Their held tasks, approver roles and owned objects are surfaced as a list for somebody to act on, because a silent reassignment produces an approver who does not know they are one.
Facts
| Protocols | SAML 2.0 · OpenID Connect — any compliant provider |
| Pricing | Not a paid tier — a security control sold as an upgrade is not one |
| Provisioning | SCIM 2.0 — the half people skip and regret |
| Roles | Mapped from your existing IdP groups |
| On SSO enforcement | Local authentication disabled entirely |
| API tokens | Tied to account state, not only to their own expiry |
| Re-authentication | Through your IdP, so conditional access applies |
| Never | A second password · automatic reassignment of a leaver's work |
Frequently asked
Is SSO on a paid tier?
No. There is no tier that withholds it and no per-provider integration to buy, because an authentication mechanism sold as an upgrade is a security control sold as an upgrade. SAML and OIDC work against any compliant identity provider you already run.
Why isn't SSO enough on its own?
Because a leaver's account still exists here. It holds roles, appears in approver lists, may be a workflow's designated approver, and can hold assigned tasks nobody will action — a workflow routing to a departed person's account stalls silently and maddeningly.
What does SCIM add?
Deactivation in your identity provider deactivates the account here, and what that person held — open tasks, approver roles, owned objects, API tokens — surfaces as a list somebody must act on. Existence of the account becomes governed, not just authentication to it.
What about API tokens issued to a leaver?
They are tied to the account's active state rather than to their own expiry alone, so deactivation closes them immediately. Tokens outliving the person who created them are the access path that never appears on a leaver checklist and surfaces during audits.
Do you have your own password login?
Once SSO is enforced, local authentication is disabled entirely. Manufacturing PLM deliberately does not implement a second password beside your identity provider, because doing so creates a credential that your security team cannot govern, cannot monitor, and cannot apply conditional access policies to.
How do signature workflows re-authenticate?
Through your identity provider, which means your conditional access policies, device posture rules and MFA requirements all apply to the signature step itself. That is the entire point of routing it there rather than prompting for a secret that Manufacturing PLM holds on its own.
Will you reassign a leaver's approvals automatically?
No. Their held tasks, approver roles and owned objects are surfaced as a list for somebody to act on deliberately. A silent reassignment produces an approver who does not know they are one, which is worse than an obviously stalled workflow.