Bring your engineers, not your accounts
An audit trail review, three months after commissioning. The asset owner's security operations team is reconstructing a series of configuration changes made to a turbine controller during the previous week. The changes were authorised — they appear in the change management system, approved, with clear engineering justification. The session was recorded by the secure remote access broker; the screen capture shows what was done.
What the team cannot reconstruct is who did it.
The session was logged into using an account called svc_oem_eng. The account is shared across the manufacturer's service organisation — perhaps eight named engineers have access to its password, distributed via the manufacturer's own internal credential management. The session recording shows the screens, but does not show which of the eight engineers was at the keyboard. The change management ticket lists "manufacturer service team" as the actor. The audit trail, in the strict sense the asset owner's compliance function needs, does not exist.
This is the identity model the manufacturer brought to the project. Perfectly normal in their own internal operations, perfectly compatible with the way their service organisation has always worked, perfectly insufficient for an EU-financed project under NIS2 .
The asset owner's expectation is straightforward. Every action against an OT asset must be attributable to a named individual person, authenticated through the asset owner's identity infrastructure, authorised through the asset owner's privileged access management process, audited under the asset owner's logging discipline. The manufacturer's engineers do not bring their own identities into the project; they receive identities from the asset owner. Service accounts for application-to-application communication exist, but they are managed and rotated by the asset owner's secret store, not held as static credentials in the manufacturer's tools. Hard-coded passwords in firmware are not configuration choices; they are delivery defects.
The principle is named-person access, time-bound, audited per person, with separation between the human identity surface and the machine-to-machine identity surface. The shorthand the security community sometimes uses is zero trust; the underlying engineering predates the label by a decade and is now mainstream in serious asset owner organisations.
What the asset owner provides
The identity infrastructure the manufacturer's engineers will integrate into is a defined stack.
The asset owner runs an enterprise identity and access management platform — typically built around Microsoft Entra ID (the platform formerly known as Azure Active Directory), Okta, Ping Identity, or a similar enterprise provider — and a privileged access management platform — typically CyberArk, BeyondTrust, Delinea, or HashiCorp Vault depending on the asset owner's preference. These platforms manage user identities, group memberships, authentication factors, session brokering for privileged access, and the audit logs for all authentication and authorisation events.
The manufacturer's engineers receive identities in this infrastructure. Each engineer has a named account: not svc_oem_eng but a personal identifier — Wei Chen, Maria Andersson, Hiroshi Tanaka. The account is provisioned through a documented onboarding process that includes background check completion, training on the asset owner's procedures, and acknowledgement of the asset owner's acceptable use policy. Multi-factor authentication is configured through the asset owner's MFA infrastructure — phone app, hardware token, FIDO2 key — not through the manufacturer's.
The account has a defined validity period. It does not exist indefinitely. The default expiry is the end of the engineer's certification on the equipment, or the end of their employment with the manufacturer, or a specific calendar date — whichever comes soonest. Renewal is a deliberate act, requiring confirmation that the engineer is still certified and still requires access.
For privileged access — the access that allows actual changes to the controllers and the SCADA, rather than read-only observation — the engineer authenticates through the privileged access management platform, which brokers session access to specific targets for specific durations under specific authorities. Standing privileged accounts on the target systems do not exist; the engineer's privileged access is established when needed and revoked when finished, with the brokered session model described earlier in this series .
IEC 62443-3-3 organises the requirements for identification and authentication under foundational requirement 1 (identification and authentication control), with the component-level requirements appearing in 62443-4-2 under the same numbering. The asset owner's infrastructure is designed to meet these requirements at SL-T 3 or above; the manufacturer's equipment is expected to be capable of integrating with that infrastructure rather than substituting for it.
Why federation does not solve this
A common manufacturer's proposal at this point in the discussion is federation — that the engineers continue to authenticate against the manufacturer's own Active Directory or identity provider, with trust established between the manufacturer's IDP and the asset owner's IAM through SAML or OpenID Connect. This is operationally simpler for the manufacturer; their engineers continue to use familiar credentials, their MFA continues to work as deployed, their identity lifecycle continues to flow through the manufacturer's HR system.
For an EU-financed project, federation is generally not accepted at the OT boundary. Three reasons.
First, the asset owner cannot validate the manufacturer's identity practices. They do not know how the manufacturer authenticates a new joiner, how they handle a leaver, how they protect against credential theft, how their MFA is configured, how compromise is detected and responded to. Trusting a federated identity is trusting the entire identity infrastructure of the federating party. The asset owner has no contractual standing to audit that infrastructure deeply, no visibility into its day-to-day operation, no ability to detect compromise in time to respond.
Second, the audit trail breaks at the federation boundary. The asset owner can record that "an identity from the manufacturer's IDP, claiming to be Wei Chen, authenticated and accessed the controller". They cannot independently verify that the identity actually was Wei Chen, rather than someone who had compromised Wei Chen's credentials at the manufacturer. Under NIS2 incident reporting obligations, the asset owner needs an audit trail they can stand behind without dependency on a third party's identity practices.
Third, the leaver process becomes asynchronous. When Wei Chen leaves the manufacturer, the manufacturer's HR system processes the departure, the IDP eventually removes the account, the federation eventually reflects the removal in the asset owner's IAM. The window between Wei Chen's last day and access removal at the asset owner's end is operationally significant for any privileged role. Federation amplifies this window; direct provisioning collapses it.
The accepted pattern is direct provisioning: the engineer has a named account in the asset owner's IAM, provisioned through the asset owner's onboarding, deprovisioned through the asset owner's leaver process, authenticated through the asset owner's MFA, audited through the asset owner's logs. The manufacturer's own identity infrastructure is irrelevant to the project's access architecture.
Federation may still be acceptable for non-OT systems — corporate collaboration tools, ticketing platforms, document repositories — where the security boundary is less sensitive and the audit obligations are different. The OT boundary specifically is where federation reaches its limit.
Service accounts and machine-to-machine identity
The pattern that applies to human engineers also applies, in a different form, to service accounts — the identities used by applications, scripts, and machine-to-machine integrations.
A turbine manufacturer's condition monitoring system pulls telemetry through a specific account on the historian. A patch deployment script logs into the controllers using a service account. A diagnostic tool authenticates to the SCADA's API. Each of these is a non-human identity, with credentials that must be managed somehow.
The historical practice — credentials hard-coded in configuration files, scripts, or firmware — is not acceptable. Hard-coded credentials cannot be rotated without re-deploying the calling system, cannot be revoked without breaking the integration, cannot be audited per use, and frequently end up in source code repositories or backup archives that nobody intended to protect. A device that ships with hard-coded credentials in its firmware is delivering a credential into the asset owner's environment without the asset owner's control.
The expectation is that service accounts are managed by the asset owner's secret store — HashiCorp Vault, CyberArk Conjur, or similar — with rotation managed by the store, retrieval by authorised consumers at runtime, and audit of every retrieval. Applications retrieve their credentials at startup or on a defined cadence, rotate them on schedule, and never persist them outside the store's protected paths.
For machine-to-machine connections where higher assurance is required, certificate-based authentication replaces password-based service accounts entirely. Each application or device has a certificate issued by the asset owner's PKI (the topic of the previous article in this series ), with the private key held in a hardware security module or equivalent. Authentication is mutual TLS; the certificate's identity is the authoritative one. Rotation of certificates replaces rotation of passwords. Audit of certificate issuance and use is part of the PKI infrastructure rather than a separate logging exercise.
Modern machine-identity frameworks — SPIFFE and SPIRE , increasingly seen in serious deployments — formalise this approach by issuing short-lived cryptographic identities to workloads and services through a workload identity attestation process. The frameworks are not yet universally deployed in OT, but the direction is clear: certificate-based machine identities, short-lived, automatically rotated, audited per use.
A device that supports only password authentication for its service interfaces is a device with an architecture limitation that will be raised at design review. Devices that support certificate-based authentication, with the certificate enrollment protocols from the cryptographic baseline article, integrate cleanly into modern identity infrastructure.
What this means for the manufacturer's organisation
The shift from team-pool access to direct named-person access has organisational consequences the manufacturer should anticipate.
The named engineers must be disclosed in advance. The manufacturer cannot operate a model in which "whichever engineer is available" handles a service call; specific engineers must be identified, vetted, onboarded, and trained on the asset owner's procedures before they can access the project's systems. For a large service organisation, this typically means a designated pool of certified engineers for the project — perhaps a dozen people, perhaps fewer — rather than an open roster.
The pool must be maintained. When an engineer leaves the manufacturer, the asset owner needs to be notified promptly. When a new engineer is added to the pool, the onboarding process runs again. When an engineer's certification on a piece of equipment expires, their access is suspended until recertification. The manufacturer's HR and certification systems need to interface with the asset owner's identity lifecycle — either through formal integration or through reliable manual notification — and the responsibility for keeping the pool current rests with the manufacturer, not the asset owner.
The manufacturer's internal practice of using shared service accounts for internal tooling does not transfer to the asset owner's environment. Inside the manufacturer's own systems, shared accounts may be efficient and operationally acceptable. Inside the asset owner's OT environment, they are not. The manufacturer's engineers will in practice have two identity surfaces: their internal manufacturer identity for their own tools and systems, and their project-specific named identity for any access to the deployed assets. Maintaining the separation between these two surfaces is part of the service organisation's discipline rather than a one-off setup task.
This duality is not unique to EU-financed projects; it is the direction industrial identity management has been moving across the global industry for the last decade. EU regulation has accelerated and codified the practice, but the underlying engineering — named-person access, time-bound credentials, certificate-based machine-to-machine authentication — is mainstream rather than exotic.
At proposal stage
A manufacturer's bid that addresses identity and access — that proposes a named pool of certified engineers for the project, describes how their credentials will be onboarded into the asset owner's IAM, commits to certificate-based authentication for the equipment's service interfaces, and demonstrates that no hard-coded credentials are present in shipped firmware — is a bid that has anticipated the conversation. The conversation that follows is operational: how the onboarding workflow integrates with the manufacturer's service rotation, what the recertification cadence will be, how leavers will be communicated.
A manufacturer's bid that proposes "secure VPN access for our service organisation using our corporate credentials" signals that the team is operating from the previous decade's identity model. The model is not unbridgeable — the same engineers can be onboarded into the asset owner's IAM, the same equipment can be reconfigured for certificate-based authentication, the same service accounts can be migrated to a managed secret store — but the work to close the gap needs to start before contract signature.
The deeper observation, similar to the one made in the cryptographic baseline article, is that this discipline pays off across the manufacturer's entire market. Named-person access, time-bound credentials, certificate-based authentication, and managed service accounts are not EU-specific requirements; they are the direction every serious asset owner's identity infrastructure is moving. A manufacturer that has adapted to deliver into one EU-financed project has adapted to deliver into the next one, and into the high-end of the global market more broadly.
The next article picks up the topic identity supports but does not by itself address: the patch delivery contract between the manufacturer and the asset owner, where the historical practice of vendor-pushed automatic updates meets the operator's expectation of controlled, scheduled, signed deployments arriving through a documented release process.
This article reflects the identity and access management landscape at publication. References to commercial IAM, PAM and secret store platforms are illustrative rather than endorsements; the underlying engineering principles apply across vendor choices. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.