Best PQC Migration Services for Industrial Device Manufacturers

Shortlist IBM Consulting for a cross-product migration program, Keyfactor if device identity and firmware signing are the hardest part, and Entrust if you need a PKI, hardware-backed signing and a documented readiness assessment. Evaluate Accenture, Deloitte and Capgemini for the integration and governance work only against an embedded scope they can demonstrate. The best team is the one that can take an actual device revision through a signed update and recovery procedure under your constraints.

This is a service procurement guide based on public provider documentation. It does not score delivery performance. Product documentation can establish what a signer or PKI supports, but it does not establish that the installed controller can verify the resulting artifact. Industrial device makers also have to keep field service, spare units and factory provisioning working through the transition.

Provider	Why shortlist it	Evidence to require
IBM Consulting	Discovery, migration sequencing and governance across systems	Embedded discovery scope and a pilot covering hardware, firmware and backend
Keyfactor	Connected-device identity and signing toolchain	Device-side verifier, boot and update path, integration owner
Entrust	Readiness assessment, manufacturing trust and signing infrastructure	Exact scope, supported keys and algorithms, verifier and factory integration
Accenture, Deloitte or Capgemini	Large program delivery or coordination across enterprise and plant teams	Named firmware and OT leads, relevant device reference and acceptance tests

IBM for inventory and migration governance

IBM Quantum Safe Transformation Services describes assessment, sequencing and migration governance. IBM Research also explains the cryptographic bill of materials. Require separate inventory entries for each hardware revision, firmware branch and signing or provisioning pipeline. A network scan can help find protocols in use. It cannot read a verification key burned into a chip or identify an offline service tool that validates a recovery image. Ask how the team combines source, binaries, vendor attestations and field configuration to fill those gaps.

Keyfactor for device identity and signing

Keyfactor’s IoT PKI and signing documentation covers EJBCA for device identity and SignServer for code signing, including firmware and software. The vendor’s migration guide discusses long-lived devices and standardized algorithms. Request an end-to-end demonstration from a build artifact to install and boot on your device. Verify which algorithms are available in the selected configuration and where the private keys live. Ask whether the commercial offer includes embedded engineering, a delivery partner or only software and support.

Entrust for manufacturing trust and a defined assessment

Entrust publishes a PQC readiness assessment schedule and a manufacturing cryptographic trust brochure. Clarify whether your proposed scope includes factory provisioning, the signing infrastructure and the device’s update and recovery code. If manufacturing is outsourced, include how suppliers authenticate a production order, provision unique devices and recover a failed unit without exporting signing keys. Check that the exact cryptographic module, service and firmware have the capabilities your policy requires.

Large integration teams for a broader rollout

Accenture’s emerging technology offering covers post-quantum security, and its industrial cybersecurity announcements describe OT work. Deloitte’s transition offering is another lead for assessment and program work. Include Capgemini where an existing industrial engineering relationship gives access to product teams and suppliers. For each, request a named firmware lead and a reference that covers a constrained device or a comparable secure update path. Plant network modernization can be useful alongside a product migration. Score it separately from changing the trust model on a device.

Give each bidder the same pilot

Pick a device with an installed base and at least two hardware revisions. Provide the boot chain and update format under the appropriate access arrangements, and give the bidder an approved lab unit to test. Require the pilot to establish:

1. Which roots and algorithms each device actually trusts, including the boot ROM, loader, update client and service tool.
2. Whether you can add a new trust path before changing signing policy. Include interrupted update and loss of power.
3. The observed effect of the intended artifacts on signature and certificate size, flash, RAM, boot time and update delivery. Use the oldest supported revision.
4. What happens when a valid image is old, an image is signed by a revoked key, or the device has been offline during a trust rotation. Include a supported recovery process and demonstrate it.
5. Who owns the resulting inventory, test fixtures, release approvals and reproducible evidence after handoff. Quote the pilot separately from scale-out and yearly support.

The NCCoE migration project treats inventory and interoperability as separate workstreams. Apply that split to your statement of work. A good inventory can still reveal a permanently constrained device. The decision for that device might be a gateway mitigation, continued support with a defined boundary, or a managed replacement.

See our cryptographic inventory guide, PQC migration plan template, migration checklist, OpenSSL migration worksheet and TLS verification guide for components of the evaluation.

FAQ

Can a new signer upgrade all installed devices?

Only devices with a compatible verifier and trust path can accept the new signing scheme. Check immutable boot roots, supported transitional formats and rescue tooling for each revision.

Should we start with firmware signatures or network encryption?

Prioritize by exposure, confidentiality lifetime, product replacement cycles and what can be migrated safely. The two workstreams may use different algorithms, teams and milestones.

Is a cryptographic inventory enough to accept a migration?

It is a discovery deliverable. Require interoperability, upgrade and recovery evidence on representative hardware before accepting implementation.

What if a legacy revision cannot accept a new root?

Record it as a specific exception with affected serial ranges, residual risks, compensating controls and an end-of-support plan. A network gateway does not change that device’s boot verification.