They should require identity assurance, certificate support, and conformity testing as part of onboarding, not after deployment. That means the device is validated as part of the supply and acceptance process, so security controls exist before the device begins interacting with people, systems, or services.
What procurement should require before a device is allowed into production
Procurement should treat device acceptance as a security gate, not a paperwork step. Before a device is approved for production use, it should already have an identity, a way to authenticate cryptographically, and evidence that the device was tested against the organisation’s required security and interoperability expectations. That shifts assurance left, before the device can reach operational trust.
A practical procurement requirement is to make those controls part of onboarding and contract acceptance. If the supplier cannot prove how the device is uniquely identified, how it presents certificates, and how it will be validated, the organisation is buying an unmanaged exposure rather than a controllable asset.
Why identity, certificates, and conformity testing belong in the acceptance process
For connected devices, identity is what allows the organisation to recognise the device as a known entity rather than an anonymous endpoint. Certificate support matters because it gives the device a cryptographic basis for trust, which is stronger than shared passwords, default credentials, or manual exceptions. Conformity testing matters because device trust is not created by policy language alone; it must be verified against the actual deployment pattern and security profile.
That is why a device should be validated before it is allowed to interact with business systems, people, or other services. If production begins first and validation happens later, the organisation often ends up compensating for the device’s weaknesses with network exceptions, isolated lanes, or manual monitoring. Those workarounds may reduce immediate friction, but they also expand operational complexity and make the control gap harder to close.
Procurement teams should also distinguish between a device that merely functions and a device that can be governed. A device that cannot present a trusted identity, support certificate-based authentication, or pass acceptance testing may still operate, but it cannot be safely folded into a controlled fleet. For that reason, procurement should require proof of device identity and onboarding readiness as a condition of purchase or go-live.
What good procurement language should force the supplier to prove
The strongest requirement language is specific and testable. It should require the supplier to state how the device is uniquely identified, what certificate or attestation mechanism it supports, and how onboarding is performed without relying on shared secrets or permanent factory defaults. It should also require evidence that the device has been tested in a manner consistent with the intended environment, including any interoperability, firmware, or configuration checks needed for safe deployment.
For buyers, the useful question is not whether the device is “secure enough in theory,” but whether the supplier can demonstrate that the security controls exist before shipment or commissioning. That evidence may include acceptance test results, certificate enrolment support, device identity documentation, and a defined process for replacing or revoking trust material if the device is reassigned, returned, or decommissioned.
When procurement sets those expectations early, security, operations, and supplier management can align on a single acceptance standard. That reduces the common failure mode where the device is purchased on feature and price, then security has to retrofit identity, trust, and validation after the device is already live.
Risk and Threat Considerations
Devices that enter production without identity assurance and certificate-backed trust create avoidable exposure. The main risk is that an unmanaged or weakly verified device becomes a trusted foothold in the environment, which can lead to unauthorised access, credential abuse, or downstream compromise of connected services.
Failure mechanism: The device is accepted on functional criteria alone, so it joins the environment without a trustworthy identity, without cryptographic authentication, or without a verified conformance baseline. That leaves the organisation dependent on post-deployment remediation, which is often slower and weaker than pre-production control.
Impact: A device that should have been constrained at onboarding can instead communicate as if it were legitimate, making detection, revocation, and blast-radius control materially harder if it is later found to be misconfigured, counterfeit, or compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Device onboarding and trust material require controlled asset and account handling before production. |
| Recommendation — Require identity proofing and onboarding controls before devices are permitted into production. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate support depends on secure authenticator lifecycle and issuance controls. |
| Recommendation — Manage device certificates and other authenticators before production activation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Production acceptance depends on controlled access and trust establishment for devices. |
| Recommendation — Define access and trust conditions that must be met before device go-live. | ||
Practitioner Guidance
What to verify: Require procurement to obtain documentary evidence of device identity, certificate or attestation support, and acceptance testing before the asset is approved for production. If the supplier cannot show how the device will be authenticated and governed, treat that as a release blocker rather than an exception to be handled later.
Decision rule: If a device cannot be enrolled, trusted, and validated before deployment, do not classify it as production-ready. Move it into a non-production test path until the supplier closes the gap or provides a different model that supports the required controls.
Practitioner takeaway: The key procurement judgement is to buy devices that can already participate in a controlled trust model, because identity and certificate support are far easier to require upfront than to retrofit after operational exposure has begun.