AKM for Oil and Gas: Encrypting OT Networks Without PKI

What is AKM, and why does it matter for OT?

Autonomous Key Management™ (AKM) is a symmetric-key protocol that encrypts and authenticates traffic between OT devices. It does not use certificates, does not require a key server to be reachable at run time, and does not require changes to PLC programs or firmware. An overview of the OT key management problem is also available on AKMSecure's OT key management page.Most OT networks today rely on network segmentation (VLANs, ACLs or security tags) to control which devices can communicate. Segmentation restricts paths, but it does not encrypt traffic. A CIP, Modbus or DNP3 frame captured on a segment can be read and, in many cases, replayed. Encryption has generally not been deployed because the available approaches each carry a significant cost. PKI requires certificate lifecycle management that OT sites are not staffed for. Firmware-level encryption requires changes that vendor support contracts often prohibit. Replacing controllers requires downtime and capital.

AKM takes a different approach. Each endpoint is provisioned once with a cryptographic seed. Both ends of a link use that seed to generate matching AES-256 keys locally, and those keys are refreshed every session without any exchange with an outside authority.

AKM can be deployed in three ways, and all three are distributed through ICS manufacturers:

1. On the network switch. The AKM software runs on industrial switches, either installed by the manufacturer or added to switches already in service where the switch model can host applications. Each switch port then acts as an AKM endpoint, and no additional hardware is needed.
2. In an AKM Inline Encrypter Module. A small device is installed between a controller and its switch port. It is used where the cable to the device itself must be encrypted, or where the switch cannot run AKM. If the module needs to be removed, the PLC is reconnected directly to the switch and the network returns to its previous configuration.
3. Embedded in the field device. For greenfield purchases, AKM can run directly on the field device, such as a PLC, a variable frequency drive (VFD) or a SCADA RTU, with the device manufacturer embedding the AKM software.

This article describes the architecture, maps it to eight oil and gas use cases, and addresses the practical concerns an OT operator is likely to raise.

Why is OT traffic usually unencrypted?

Many current PLCs, RTUs and field devices support certificate-based security, but it is rarely enabled in the field. The reasons are practical rather than technical, and they fall into five areas.

As a result, most sites rely on segmentation and monitoring. Recent incidents show the limits of that approach. Volt Typhoon maintained access to U.S. critical infrastructure networks for at least five years using valid accounts and default vendor credentials. CyberAv3ngers compromised at least 75 internet-connected PLCs between November 2023 and January 2024, all of which had default passwords or none. In both cases, once the attacker had network access, nothing further was needed to communicate with the devices.

Where are the exposures in oil and gas facilities?

• On a well pad, any skid connected to the pad switch can communicate with any other skid, and captured traffic is readable.
• The radio, cellular or fiber link between a pad and its gathering station carries every poll in the clear.
• A historian collector on the supervisory network can usually reach every unit PLC, not only the ones it needs.
• A maintenance laptop connected to a station LAN often remains a usable path after the work is finished.
• Vendor-supplied skids are often covered by support contracts that prohibit firmware changes. The only options today are to replace the PLC or to leave its traffic unencrypted.
  

How does AKM work?

In AKM, endpoints that are allowed to communicate share a cryptographic seed. This shared seed defines a relationship. A relationship can link two endpoints, or it can be multipoint, linking three or more endpoints through an ATR. Each member uses the seed to generate the same symmetric keys independently, so no keys or certificates are exchanged over the network. A device that is not a member of a relationship cannot decrypt its traffic.

The protocol works in four stages:

1. Seed provisioning. Each endpoint is provisioned with a seed once, at installation. All later key material is derived from it on the device.
2. Key refresh. Keys are refreshed every session. Because both ends derive the keys from the same seed, no renewal or revocation step is needed.
3. Packet verification. Each packet is authenticated, so a device on the same network segment cannot inject or alter traffic without the relationship.
4. Recovery. If a session is interrupted, the endpoints re-establish it automatically without operator action.
   

The cryptographic primitives are AES-256 for encryption and SHA-384/512 for integrity. Keys can optionally be held in an HSM. Because the design uses only symmetric cryptography, it is not exposed to the quantum attacks that affect RSA and elliptic-curve algorithms, and it aligns with CNSA 2.0 guidance. Since no external authority is involved at run time, AKM operates on segmented, intermittent and air-gapped networks.

What design rules apply on site?

The same five rules apply at every site:

1. Only members of a relationship can communicate. Traffic within a relationship is encrypted with keys held only by its members, whether that is two endpoints or a multipoint group.
2. Each flow uses one path. A flow either uses its own port-to-port relationship or uses the shared encrypted link between two switches, but not both.
3. The list of allowed pairs is maintained outside AKM. The switch manufacturer's network policy tool defines which devices may communicate, either as pairs or as groups. AKM creates relationships only for those pairs and groups.
4. The AKM Provisioning module (APM) is not in the data path. It approves, issues and retires relationships but does not forward process traffic.
5. Controllers that cannot be modified use an Inline Encrypter Module. The module encrypts traffic between the controller and the switch, and no change is made to the controller.

The reference design uses two classes of switch. Industrial edge switches are used at the plant edge, where each switch port acts as an endpoint. Aggregation switches are used on uplinks between sites. On those links, AKM runs on the switch and encrypts the uplink without a certificate or an external key server.

Can a relationship include more than two devices?

AKM supports both point-to-point and multipoint relationships. In a multipoint relationship, three or more endpoints are linked by an ATR and share the same key material. Communication patterns that can use a multipoint relationship include:

• A SCADA master polling several RTUs over a shared radio channel.
• A group of PLCs on one skid or unit that exchange data with each other.
• A historian or monitoring collector reading from a defined set of controllers.
• Multicast traffic, such as IEC 61850 GOOSE messages, where one publisher sends to several subscribers.

Group membership is defined in the same policy tool as the allowed pairs. A device outside the group cannot decrypt the group's traffic. When a member is removed, the remaining members must move to new key material so the removed device can no longer read the traffic.

How is AKM deployed?

AKM is intended to be supplied through the ICS manufacturers that operators already buy from, rather than as a separate security appliance. It can be installed on the network switch, deployed in an AKM Inline Encrypter Module in front of an individual device, or, for new equipment, embedded in the field device itself. Most sites would use more than one model.

  Figure 1. Where encryption starts with AKM installed on the switch (A), in an Inline Encrypter Module (B) and embedded in the device (C) 

Figure 1 shows a pad-to-station link under each model. In each case the AKM Provisioning module distributes key material to the AKM endpoints but does not carry process traffic, and the safety system is wired separately and is not part of any relationship.

How do you choose a deployment model?

The main difference is where encryption begins. With AKM installed on the switch, traffic is encrypted from the switch port onward, so the cable between the device and the port is the only unprotected segment. That is acceptable where the device and the switch share a locked cabinet, and it avoids adding hardware. Where that cable runs through an open area, or where the switch cannot run AKM, the Inline Encrypter Module moves the start of encryption to the device itself. For new equipment, the most direct option is AKM embedded in the field device. Encryption then begins inside the PLC, drive or RTU, so no segment of the path is unencrypted and no additional hardware is needed.

Why supply AKM through the ICS manufacturer?

• The product comes from a manufacturer the operator has already qualified and audited, so no new vendor approval is needed.
• Support is provided through the same channel and agreement as the controllers and network equipment it protects.
• The manufacturer can test the Inline Encrypter Module against its own PLC families and protocols, which reduces the operator's own testing.
• A manufacturer-qualified accessory that requires no change to PLC logic and can be removed in one step is a smaller management-of-change submission than a new vendor's appliance.
• A cataloged module follows the same lifecycle and spares process as the equipment it is installed with, which matters for controllers that stay in service for 15 to 20 years.

How do the deployment models work together?

AKM installed on switches covers both new network segments and existing switches that can host it. The Inline Encrypter Module covers devices whose cable to the switch is exposed, and switches that cannot run AKM. AKM embedded in the device covers greenfield purchases, where the operator can specify AKM support when selecting PLCs, drives and RTUs.

All three models follow the design rules described above. The allowed-pair list stays in the manufacturer's policy tool, the AKM Provisioning module on the switch approves each relationship, and an Inline Encrypter Module in front of a PLC acts as one endpoint of a relationship, as does a field device with AKM embedded. The use cases below use industrial edge switches and aggregation switches as the reference hardware.

Where does AKM fit in an oil and gas facility?

The eight patterns below cover production, drilling, packaged equipment, refining, midstream and mixed facilities. Each uses equipment that is already common in these facilities and has a defined test of success.

Where a use case lists an Inline Encrypter Module, AKM installed on the switch can be used instead if the cable between the device and its switch port is physically protected, for example inside a locked panel. This removes the need for additional hardware at that location.

What concerns do OT operators raise, and how are they answered?

This section lists the concerns OT operators most often raise about adding encryption to a control network, with a response to each.

Safety and availability

Concern: an inline device in the control path is a new point of failure.

The Inline Encrypter Module does not change the PLC. If it has to be removed, the PLC is reconnected directly to the switch and the network returns to its original configuration. AKM also re-establishes interrupted sessions automatically. Initial installations are limited to supervisory and polling paths and are not placed on protection or shutdown paths.

Concern: the failure behavior of an inline device must match the site's priorities.

With AKM, failure behavior is configurable. An Inline Encrypter Module can be set to fail open, so that traffic continues to pass unencrypted if the module fails and availability is preserved, or to fail closed, so that traffic stops rather than passing without protection. The setting can be chosen device by device, so a site can favor availability on one path and security on another.

Concern: encryption will add latency that the control loop cannot tolerate.

The latency concerns CISA has raised for OT relate to asymmetric signature operations and certificate checks on constrained devices. AKM uses only symmetric operations. AKMSecure's figure for an AKM handshake is under 1 ms, compared with 300 to 700 ms for a typical PKI handshake. Data packets are not subject to a per-session certificate exchange.

Concern: encryption must not be applied to safety systems.

Safety systems are out of scope. The safety PLC, safety instrumented system, blowout preventer and certified shutdown systems are not placed in any AKM relationship. IEC 61511 requires these systems to remain independent of the basic process control system, so they stay wired separately from the AKM path.

Concern: if the two ends lose key synchronization, communication will stop.

Both ends derive the same key from the same seed, so the key itself cannot drift. A shared clock determines when each refresh occurs. Clock skew between the two ends is therefore the condition that must be managed.

Concern: the shared clock becomes a dependency, and a lost or spoofed time source could interrupt communication.

The shared clock is used only to schedule key refresh, not to derive keys, but the two ends must agree on time for refresh to stay in step. On an air-gapped site the time reference is typically a local source such as a GPS receiver, a PTP grandmaster or a site NTP server. Because a lost or spoofed time source can cause the endpoints to fall out of step, the time source should be treated as part of the security design, protected in the same way as other critical infrastructure services, and monitored for skew.

Change control and vendor relationships

Concern: PLC firmware cannot be changed under the vendor support contract.

No firmware change is needed. The Inline Encrypter Module is installed in front of the PLC, so the vendor firmware and the PLC program are not modified.

Concern: the network and protocols would have to be re-engineered.

CIP, Modbus and DNP3 are used unchanged. The reference design uses industrial edge and aggregation switches of the kind already common in these facilities, and AKM can be installed on switches already in service where the switch model can host applications. The list of allowed device pairs remains in the switch manufacturer's network policy tool, which the OT team already maintains.

Concern: this adds another vendor to the plant floor.

AKM is supplied through ICS manufacturers, embedded in their industrial switches, as an Inline Encrypter Module in their catalog, or embedded in new PLCs, drives and RTUs. Where the site already uses that manufacturer's switches, no new hardware vendor is introduced. Procurement, support and spares go through the existing manufacturer channel.

Concern: management of change approval will take too long.

The change is limited in scope. There is no change to PLC logic or protocols, no involvement of the safety system, and the module can be removed in one step. That is a smaller change than replacing a controller or adding encryption in firmware.

Operations and staffing

Concern: the sites do not have staff with cryptography expertise.

AKM has no certificate lifecycle to manage. Each endpoint is provisioned once, keys are refreshed automatically, and the allowed-pair list is maintained in existing OT tools. No ongoing cryptographic administration is required at the site.

Concern: certificate renewal at remote sites requires a site visit.

AKM does not use certificates, so there is nothing to renew. Keys are refreshed on the device, and interrupted sessions recover without a site visit.

Concern: a failed device must be replaced quickly, often at night and without specialist staff.

A replacement switch, Inline Encrypter Module or field device is provisioned for its relationships by the APM. Because the allowed-pair list is held in the switch manufacturer's policy tool rather than in the failed device, the replacement takes on the same relationships as the unit it replaces, and the far end of each relationship does not need to be reconfigured.

Concern: AKM itself will need software updates over a 15 to 20 year asset life.

AKM is patchable. Updates are administered centrally through the APM, so AKM software on switches, modules and embedded devices can be maintained without visiting each endpoint.

Concern: encrypted traffic will prevent OT network monitoring.

The PLC side of each Inline Encrypter Module carries the same unencrypted traffic as today, so a monitoring sensor placed on that side sees the full traffic. Alternatively, the monitoring collector can be given its own relationships in the same way as the historian.

Concern: encrypted traffic will make incident response and forensics harder.

Operators can recover their own traffic for investigation. Captured traffic can be decrypted using the AMM, or a capture station running Wireshark can be added as a member of a multipoint relationship, so that it receives and decrypts the same traffic as the other members.

Concern: emergency maintenance access must be available at any time.

The maintenance port has its own relationship, which is enabled when a job is opened and disabled when it is closed. A technician laptop is admitted only during that window. If necessary, the module can be removed and the PLC reconnected directly to the switch.

Connectivity

Concern: sites are air-gapped, intermittently connected or on satellite links.

AKM does not need to reach a certificate authority, revocation service or key server, so it operates without external connectivity. The rig-to-shore use case was designed for a high-latency, often one-way link. Data is delivered without a handshake, and loss of the return path does not stop the outbound feed.

Concern: links are metered and cannot carry additional overhead.

AKM generates no certificate exchanges, revocation checks or renewal traffic. Per-packet overhead from encryption and authentication still applies and should be measured.

Security architecture

Concern: the site already has segmentation, firewalls and monitoring.

AKM is intended to work alongside segmentation, not to replace it. A VLAN or a security group tag controls where an unencrypted frame can go, but it does not protect the contents. In the Volt Typhoon and CyberAv3ngers incidents, network access was sufficient to communicate with the devices. With AKM in place, a device without a relationship cannot read or inject traffic, even on the same VLAN.

Concern: existing standards such as OPC UA security or DNP3 Secure Authentication already address this.

OPC UA security and DNP3 Secure Authentication both depend on certificates or on device support. Where devices support them, they are often left disabled for the reasons described earlier, and many older devices do not support them at all.

Concern: a seed is equivalent to a pre-shared key, which is considered poor practice.

The seed is not used to encrypt traffic directly. It is used to derive session keys, which are refreshed every session, so a captured session key cannot be used later. The seed is the asset that must be protected, both during provisioning and at rest. HSM storage is supported for this purpose.

Concern: there must be a way to recover if a seed is exposed, and to retire a device that is decommissioned.

Seeds are issued and retired through the APM. If a seed is suspected to be exposed, the affected relationship is given a new seed and the old one is retired, after which keys derived from the old seed are no longer accepted. When a device is decommissioned, its relationships are retired in the same way, so the device can no longer communicate with its former peers.

Concern: the AKM Provisioning module could be compromised.

The AKM Provisioning module approves, issues and retires relationships. It does not forward process traffic, and it cannot create a relationship that is not in the allowed-pair list held in the network policy tool. Compromise of a pad switch does not expose the keys used at the station.

Concern: AKM does not help if an authorized device or engineering workstation is itself compromised.

That is correct, and it is a boundary of what AKM does. AKM authenticates and encrypts traffic between authorized endpoints. It does not inspect the commands those endpoints send, so a compromised device can still send valid traffic within its own relationships. What AKM does is limit how far that compromise can reach, because a device can only communicate with the peers it has relationships with. Keeping engineering workstation relationships narrow, and enabling maintenance relationships only while a job is open, keeps that reach small. Application-layer controls and OT monitoring remain necessary alongside AKM.

Concern: the cryptographic design is proprietary.

The primitives are standard: AES-256 for encryption and SHA-384/512 for integrity. The seed-based key derivation method is covered by seven AKMSecure patents, four granted and three pending. The operator's cryptography team can review the design as part of due diligence.

Standards and certification

Concern: how does AKM map to IEC 62443 and NERC CIP?

The foundational requirements of IEC 62443 begin with identification and authentication, which AKM applies to every session and every packet. For electric utilities, AKM supports NERC CIP-012 protection of real-time data exchanged between control centers. AKMSecure staff have contributed to IEC 62443 and CENELEC TS 50701, and AKMSecure is a member of the OT Cyber Coalition. The symmetric-only design is consistent with CNSA 2.0.

Concern: procurement requires FIPS 140-3 validated cryptography.

AKM uses the wolfCrypt FIPS 140-3 cryptographic module, which is validated under NIST's Cryptographic Module Validation Program (CMVP). The AES-256 and SHA-384/512 operations described earlier are performed by that validated module.

Concern: IEC 62443 and NERC CIP-007 require security event logging.

Audit logging is part of AKM's default configuration, and the APM gathers statistics from all endpoints. This gives operators a central record of AKM activity across the site to support their logging and audit obligations.

Concern: the module must be rated for hazardous locations.

The Inline Encrypter Module must carry the area classification required at its installation point, as with any other device on a classified pad, skid or platform.

Cost, scale and supplier risk

Concern: cost across thousands of devices.

AKM does not incur the recurring costs associated with PKI: certificate issuance, renewal, integrator labor and site visits. AKMSecure estimates its total cost of ownership at roughly 10 percent of a comparable PKI deployment. The cost structure also changes. With PKI, each device carries a recurring cost for every certificate renewal, so total cost grows with the number of devices and with time. AKM trades that marginal cost for a fixed cost: each endpoint is provisioned once, and there is no recurring per-device certificate cost after that.

Concern: scaling to every pad and station.

The allowed-pair list is managed in the policy tools the operator already uses. Keys are derived on each device rather than issued centrally, so there is no certificate authority to become a bottleneck. Deployment can expand one use case at a time.

Concern: where has this been deployed?

The use cases in this article are reference designs and have not yet been deployed at an operator site.

Concern: the supplier may not be around for the full life of the equipment.

Operators plan around assets that stay in service for 15 to 20 years, so this is a reasonable question to ask of any security supplier. AKM is delivered through ICS manufacturers and embedded in their switches, modules and field devices, so long-term support follows the manufacturer's own product lifecycle commitments rather than depending on a separate security vendor. Operators who need additional assurance can address it in procurement, for example through source-code escrow terms.

What does this mean for OT operators?

The practical obstacle to encrypting OT traffic has not been the cryptography. It has been the cost of adding encryption without changing PLC logic, safety systems, protocols or site staffing. AKM addresses those constraints by deriving keys on each device from a provisioned seed, so there are no certificates to renew and no external authority to reach. It is supplied through ICS manufacturers, and the Inline Encrypter Module can be removed in one step if needed.

About AKMSecure

AKMSecure delivers a patented Autonomous Key Management protocol built to replace outdated PKI approaches with a dynamic, quantum-secure, air-gapped-capable architecture. Instead of relying on persistent credentials that can be stolen, reused, or abused, AKM enables independently verified sessions with no standing privileges left behind. The result is a model that better aligns with Zero Trust principles, reduces certificate-based risk, and supports resilient operations across enterprise IT, OT and Tactical Edge environments. Built to NSA-grade security standards and deployable as a lightweight SDK, AKMSecure helps organizations modernize trust at the protocol layer without rebuilding everything around it.