SSO and identity for plant software

Office software gets one user per laptop, a stable headcount and an IT department down the hall. Plant software gets shared tablets in a control room, a contractor population that doubles during a turnaround and halves a month later, and a site network that may not reach the drum where the reading is taken. Identity is harder here, and the consequences of getting it wrong land on the audit trail that your API 510 and API 570 records depend on. This paper covers what single sign-on (SSO) should do for an inspection platform, which protocol to require, what SSO does not cover, and how identity survives a shared device.

Why does identity matter more in plant software than in office software?

Three properties of plant work make identity a first-order control rather than a convenience.

• The records are evidence. An inspection finding, an approved interval or a repair sign-off carries a name. If the name is a shared login, the record is unattributable and the audit trail behind it is worthless in an investigation.
• The population churns. A turnaround brings in NDT crews, scaffolders and specialist inspectors for weeks. Every one of them needs access on day one and must lose it at demobilization. Manually created accounts in a vendor's user list are the ones that never get removed.
• The devices are shared. A crew may run three tablets among eight people. The identity that logged the device in is not the identity that took the reading or signed the form.

SSO addresses the first two directly and sets up the third. It moves authentication to the corporate identity provider (IdP) where joiners, movers and leavers are already managed, and it makes the inspection platform a relying party rather than another password store.

SAML 2.0 or OpenID Connect: which should inspection software support?

Both protocols let an application trust an external IdP. They differ in age, format and fit.

SAML 2.0 is XML-based, browser-redirect oriented and widely deployed in older enterprise identity infrastructure. It works well for web applications. It is awkward for mobile apps and APIs because the assertions are large, browser-bound documents rather than tokens a native app can carry.

OpenID Connect (OIDC) is a thin identity layer over OAuth 2.0. It issues signed JSON tokens that a web app, a mobile app and an API client can all use. It is what modern IdPs default to and what mobile platforms support natively.

For an inspection platform that has a web console, a field app on tablets and an API for integrations, OIDC is the right requirement. The practical objection ("our IdP is SAML") is usually smaller than it sounds. Microsoft Entra ID and Okta both present OIDC to applications regardless of how they federate upstream, so a company whose identity ultimately lives in an older SAML directory can still connect through Entra or Okta over OIDC. Ask the vendor which IdPs they have connected in production and whether a generic OIDC provider is supported for the ones they have not.

What to look for in the OIDC implementation itself:

• Support for the IdPs you actually run, plus a generic OIDC option.
• Group or role claims from the IdP mapped to platform roles, so assignment happens in the directory.
• Token lifetimes you can set, and a design where a permission change invalidates stale tokens rather than waiting for expiry.

What does SSO change about contractor onboarding and offboarding?

The turnaround contractor is the hardest identity case in the plant, and it is where SSO earns its place.

Onboarding. With SSO, giving a contractor access is a group membership in the IdP (or in a guest directory such as Entra B2C for people who are not employees). The platform sees the user on first login, reads the group claim and assigns the role. No vendor user list is edited by hand.

Scoping. SSO establishes who the person is. It does not say what they may see. That comes from the platform's data entitlement, ideally granted at a node of the asset hierarchy so a crew scoped to one unit sees that unit's vessels, piping and CMLs and nothing else. Combine the two: the IdP says "this is a contract UT technician," the platform says "on the crude unit."

Offboarding. When the contract ends, the account is disabled in the IdP. The platform refuses the next login. If tokens are invalidated on permission change, even an open session ends. This is the single largest improvement SSO makes to a plant's access hygiene, because the vendor-side account that nobody remembered to delete stops existing as a category.

A test to run during evaluation: disable a test user in your IdP, then try to log in to the platform and to use an existing session. Time both.

Is MFA necessary if SSO is on?

SSO moves authentication to the IdP, and most IdPs enforce multi-factor authentication (MFA) there. So why does the platform need MFA at all?

Because SSO never covers every account. There are always:

• Local accounts for a tenant that has not federated yet, or for a pilot.
• Break-glass administrators who must be able to get in when the IdP is down or misconfigured.
• Small contractors who have no IdP of their own and are not yet in your guest directory.

For these, the platform should offer time-based one-time password (TOTP) MFA with recovery codes. TOTP works with the authenticator app people already carry, needs no hardware token program, and the recovery codes cover the lost-phone case without a helpdesk reset that itself becomes a social-engineering path.

The MFA secrets deserve their own attention. A TOTP seed is a shared secret; if the database is read, every seed is compromised. Ask whether the seeds are encrypted at the application layer, separately from database-level encryption at rest, so that a database read alone does not yield working second factors.

How do shared field devices and signatures work with SSO?

The shared tablet breaks the office assumption that one login equals one person. A crew lead logs the device in at the start of the shift; three technicians take readings and two inspectors sign forms on it before the shift ends.

Two designs handle this honestly:

1. Per-signer identity at signature time. The form's signature widget asks the signer to identify themselves, independently of the device login, and records that identity with the signature. The device session establishes that the tablet is trusted; the signature establishes who signed.
2. Capture attribution. Readings and photos are attributed to the technician who took them where the workflow allows a hand-off, rather than to whoever logged in.

Electronic-signature rules such as 21 CFR Part 11 require each signing to carry the signer's name, the date and time, and the meaning of the signature. A shared login cannot satisfy that. Per-signer identity on a shared device can.

Offline capture adds a wrinkle: the device may be out of coverage for the whole shift, so identity checks at signature time must work against credentials cached on the device, and the data waiting to sync must be encrypted at rest on the device.

How should service accounts and API keys be identified?

Integrations are users too. The historian that pushes operating data, the reporting job that pulls a monthly export and the workbook import someone scripted all act on records. If they act under a person's credentials, the audit trail lies about who did what and the account outlives the person.

The right design:

• API keys are tenant-bound signed tokens tied to a role. The key can do what its role can do, in one tenant, and nothing else.
• Keys are self-service for the tenant, so an integration owner can issue and revoke without a vendor ticket, and issuance and revocation are audit events.
• Key actions appear in the same audit trail as human actions, with the key's identity as the actor.

An integration key with no role is an administrator you forgot you created.

How intelliSPEC handles it

intelliSPEC authenticates through OpenID Connect, with production connections to Microsoft Entra ID, Entra B2C (for external and contractor identities), Okta and any generic OIDC provider. Tenants set up SSO themselves; roles are assigned from the platform's seven default roles, custom roles or role templates.

For accounts that do not come through the IdP, TOTP MFA with recovery codes is available. MFA secrets are encrypted at the application layer with AES-256-GCM, separately from the AES-256 encryption at rest on the database and object storage. Permission changes invalidate stale tokens, so a role removed in the morning does not linger in an open session until the afternoon.

Data entitlement is node-level over the asset graph (company, site, facility, asset, component, weld), so a contractor authenticated through your IdP can be scoped to a single unit. API keys are tenant-bound signed tokens tied to a role, issued through tenant self-service, and every login, permission denial and tenant switch lands in the hash-chained audit trail with actor, tenant, request id, IP and user agent.

On a shared field tablet, the signature widget captures per-signer identity, and offline data is encrypted at rest on the device with no time limit on the local store. Identity controls are designed against the SOC 2 Trust Services Criteria and are documented in the Trust Center. For how identity meets the crew roster during a turnaround, see intelliCREW and intelliPROJECTS; terms are defined in the glossary.