They should verify whether the device can authenticate strongly, whether its certificate lifecycle can be managed, and whether the hardware, software, and firmware provenance is documented. If any of those checks fail, the device should not be treated as trustworthy simply because it is operationally useful.
What IAM and OT teams should verify before admitting a connected device
Teams should not treat a device as trusted just because it powers on, talks on the network, or appears to be operationally necessary. Admission should depend on whether the device can prove its identity strongly, whether its certificate lifecycle can be governed, and whether its hardware, software, and firmware provenance are documented and reviewable.
Why device admission is an access decision, not just an inventory check
A connected device is effectively asking for access to a production environment, so the admission decision should be handled like a trust decision. The key question is whether the device can be recognized, authenticated, and maintained over time, not merely whether it is physically present or functionally useful. A device that cannot be bound to a stable identity and lifecycle tends to become a blind spot once it is deployed.
That matters in OT because devices often stay in service for long periods, may be difficult to patch, and can have broad operational reach once admitted. In practice, the admission process should separate “works today” from “can be trusted tomorrow,” especially where remote management, vendor maintenance, or safety dependencies are involved.
What to verify before admission
First, verify the authentication method. The device should support strong, device-level authentication rather than shared credentials, hardcoded passwords, or ad hoc exceptions. Where certificate-based authentication is used, the team should confirm that issuance, renewal, revocation, replacement, and expiry handling are all operationally supported.
Second, verify certificate lifecycle control. If the team cannot rotate a certificate without breaking operations, or cannot prove how the certificate will be renewed and revoked, then the device is not ready for trusted admission. A certificate that cannot be managed safely creates future outage and compromise risk even if the initial onboarding looks successful.
Third, verify provenance. The team should be able to document the device’s hardware source, software bill of materials, and firmware lineage well enough to understand what is running and who is responsible for it. If provenance is opaque, the device may be impossible to assess for tampering, unauthorized modification, or unsupported components.
These checks are strongest when they are performed before the device is allowed to interact with critical systems. If a device cannot satisfy them, the safer decision is to keep it segregated until the control gap is closed.
Risk and Threat Considerations
Admitting an unverified connected device can expand the attack surface, create unmanaged trust relationships, and leave the organisation with a device that is hard to revoke, rotate, or investigate after compromise. In OT environments, that can turn one weak endpoint into a persistent entry point or a difficult recovery problem.
Failure mechanism: weak or shared authentication, unmanaged certificates, or undocumented firmware can let a device impersonate a trusted asset or remain reachable after its trust should have expired.
Impact: the environment may inherit hidden access paths, delayed detection, and a larger blast radius if the device or its supplier chain is compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Connected devices and external equipment need strong machine authentication before admission. |
| IA-5 — Authenticator Management | Certificate lifecycle control is central to admitting and maintaining device trust. | |
| IA-2 — Identification and Authentication (Organizational Users) | Admission decisions mirror identity proofing and authentication discipline for trusted access. | |
| Recommendation — Use IA-9 to require strong device authentication before allowing a connected device onto trusted networks. Use IA-5 to manage certificate issuance, rotation, renewal, and revocation for connected devices. Apply IA-2 principles to ensure access is granted only after strong identity proof. | ||
Practitioner Guidance
What to verify: require evidence of device authentication, certificate handling, and provenance before onboarding, and make the admission owner accountable for producing that evidence. If the evidence is incomplete, treat the device as untrusted until it is remediated or isolated.
Decision rule: if the device cannot be rotated, revoked, or re-issued without breaking operations, do not admit it into a trusted zone. Operational convenience is not a substitute for recoverable trust.
Practitioner takeaway: the right admission standard is not “can we make it work,” but “can we prove, maintain, and withdraw trust in it over its full lifecycle?”
Related resources from NHI Mgmt Group
- What should IAM teams verify before adopting a hybrid access model?
- What should IAM teams verify before approving a sovereign security platform?
- How should defence and security teams verify hardware supply chain risk before deploying connected systems?
- What should IAM teams verify before enabling per-tenant user isolation?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org