How should manufacturers implement ISO/IEC 27001:2022 cryptography controls across both IT and OT environments?

How should manufacturers implement cryptography across IT and OT?

Manufacturers should separate the policy question from the deployment question. IT and OT often need different key lifecycles, device constraints, and change windows, but the control objective is the same: approved algorithms, known owners, and documented cryptoperiods. The practical test is whether every cryptographic asset can be found, assigned, rotated, revoked, and audited without breaking production safety or availability.

That means cryptography should be managed as a governed service with clear ownership, not left to individual plants, platforms, or vendors. For a manufacturing programme, the hard part is usually consistency across environments: certificate sprawl in IT, embedded constraints in OT, and exceptions that become permanent if no one owns the review cycle. ISO 27001 Certification Guide is useful here because it frames cryptography inside the broader ISMS work of scope, risk treatment, and Statement of Applicability discipline.

A workable implementation also needs a complete cryptographic inventory. That inventory should cover certificates, keys, algorithms, trust anchors, hardware security modules where used, and the service or asset that depends on each item. In OT, the inventory must include controller-side and vendor-managed dependencies as well as corporate systems, because a missed asset can become an outage during rotation or renewal. ISO 27002 Controls Guide helps translate that inventory into control selection and implementation detail across the Annex A catalogue.

What changes when cryptography spans both IT and OT?

The biggest change is operational tolerance. IT systems can usually absorb more frequent rotation, certificate renewal, and stronger algorithm transitions than legacy OT components, which may have long maintenance windows, older firmware, or vendor-supported cryptographic limits. Manufacturers should therefore treat the cryptographic standard as common, while allowing the operating model to differ by asset class, criticality, and downtime tolerance.

That distinction matters most for key lifecycle management. Centralised control should define how keys are generated, protected, rotated, suspended, revoked, archived, and destroyed, while local teams implement the approved process within their environment constraints. NIST SP 800-57 Key Management is the clearest external reference for lifecycle discipline, especially where cryptoperiod, rotation timing, and algorithm selection need to be defensible.

OT also changes the risk boundary. If cryptography is embedded into industrial controls, the failure mode is not just confidentiality loss, it can become loss of availability or unsafe fallback behaviour. That is why manufacturers should test certificate expiry, key rollover, and trust-chain replacement in staging or engineering replicas before change is pushed to production. Where industrial systems are involved, NIST SP 800-82 Rev 3, OT Security Guide provides the architectural context for planning those changes safely.

Which controls make the programme auditable and sustainable?

The control set should be simple enough to run continuously and strict enough to survive audit. At minimum, manufacturers should define approved algorithms, minimum key sizes, ownership, renewal thresholds, revocation triggers, and exception handling. They should also make sure the SoA references the actual operating decisions, not just the abstract requirement, so the implementation is traceable from policy to plant floor.

Good evidence is operational evidence. Auditors and internal reviewers should be able to see inventories, renewal logs, revocation records, exception approvals, and proof that cryptographic changes were tested before deployment. The point is not just to say that cryptography is used, but to show that it is governed consistently. For practical control structure and control-by-control mapping, ISO/IEC 27002:2022 Information Security Controls remains the most direct companion to iso 27001 implementation.

Risk and Threat Considerations

Cryptography failures in manufacturing often start as hygiene issues and end as production risk. Expired certificates, unmanaged keys, and undocumented exceptions can interrupt remote access, machine-to-machine trust, firmware validation, or secure telemetry. In OT, those failures can also trigger unsafe fallback states, because systems may fail closed, fail open, or stop trusting upstream services when a trust anchor changes unexpectedly.

Failure mechanism: The organisation loses visibility into where keys and certificates are used, so rotation or renewal breaks an untracked dependency, or a stale credential remains valid long after it should have been revoked.

Impact: The result can be service interruption, loss of trust between IT and OT systems, failed authentication, delayed recovery, or exposure if a compromised key remains active longer than intended.

Practitioner Guidance

What to prioritise: Start with inventory and ownership before tuning algorithms. If you cannot map a certificate or key to a business service, plant, or owner, you do not yet have a controllable cryptography programme.

Decision rule: If a cryptographic item supports a live OT process, treat rotation and revocation as change-managed events with testing and rollback, not as routine IT hygiene. If the item is IT-only, standardise the lifecycle more aggressively and shorten exception duration.

What good looks like: Every cryptographic asset has an owner, a renewal date, an approved algorithm, and an agreed failure path. Exceptions are time-bound, reviewed, and tied back to the SoA or risk treatment decision that justified them.

Practitioner takeaway: The objective is not “more cryptography”, but governed cryptography that can be operated consistently across two very different production environments without creating hidden dependencies or unplanned downtime.

Related resources from NHI Mgmt Group

• How should security teams implement DLP across SaaS, cloud, endpoints, and GenAI environments to meet ISO 27001 expectations?
• How should security teams implement ISO 27001:2022 compliance in environments with SaaS, cloud, and AI tools?
• How should security teams structure ISO 27001 controls for human users, non-human identities, and applications across cloud and SaaS environments?
• Why does ISO/IEC 27001:2022 fit cloud-native organisations better when they use existing tools and free controls?