What Is CIP Electronic Keying?
Electronic keying is the check that stops the wrong device, or the wrong firmware, from silently taking over a connection when hardware is replaced. It is also the setting behind a keying-mismatch fault after a swap or a firmware update. This page explains what CIP electronic keying is, how the Exact Match, Compatible Module, and Disable Keying options differ, and how to choose among them without leaving a real gap.
CIP Electronic Keying in one line: CIP electronic keying makes a controller check a device's identity - vendor, product code, and revision - against what the configuration expects before opening a connection. Exact Match requires all of it including revision; Compatible Module allows a revision the device declares compatible; Disable Keying skips the check. Stricter keying prevents wrong-device errors but requires updating configuration on firmware changes.
What Keying Checks and Why
When a controller opens a connection to an EtherNet/IP device, the connection request can carry the identity the controller expects: vendor ID, device type, product code, and revision. The device compares those against its own Identity object and accepts the connection only if they satisfy the keying rule. The point is to guarantee that the physical device in a slot is the one the program was written for, so a maintenance swap cannot quietly put a different or incompatible module into service and have the logic run against it as though nothing changed.
The values being compared come straight from the CIP Identity object: vendor ID, product code, and the major and minor revision. This is why a keying error is really an identity disagreement, and why the fault message usually tells you which field did not match - a different product code means the wrong model is present, a different revision means the firmware is not what the configuration expected.
Exact Match, Compatible Module, Disable Keying
The three keying levels are a spectrum from strict to none.
| Keying level | What must match | Best for |
|---|---|---|
| Exact Match | Vendor, product code, major and minor revision - all exact | Validated, revision-locked systems |
| Compatible Module | Vendor and product code, plus a revision the device declares compatible | Normal operation allowing minor upgrades |
| Disable Keying | Nothing - the connection opens regardless | Rare, deliberate cases only |
Exact Match is the strictest: the device must be the same model at the same major and minor revision, so any firmware change forces a configuration update before the connection will open. Compatible Module is the common working setting: it fixes the model but lets the device accept a revision it declares backward-compatible with the requested one, so a minor firmware upgrade does not break the connection. Disable Keying turns the check off entirely.
The choice is a real risk decision. Exact Match gives the strongest guarantee and the most maintenance friction. Compatible Module trades a little strictness for the ability to upgrade firmware within a compatible family without reconfiguring. Disable Keying should be a deliberate, documented exception, because a device with keying disabled will accept a connection even if someone installs the wrong module entirely - exactly the failure keying exists to prevent.
Diagnosing and Choosing Keying
A keying mismatch after a firmware update is the classic case: the device is correct but its revision no longer matches an Exact Match configuration, and the connection is refused until the configuration is updated to expect the new revision, or the keying is relaxed to Compatible Module. A mismatch after a hardware swap usually means the replacement is a different product code - the wrong part was pulled from stores - and the correct fix is the correct part, not weaker keying. Reading the fault detail against the CIP general status codes tells you which case you are in.
For most systems, Compatible Module is the sensible default: it catches wrong-model swaps while tolerating in-family firmware upgrades. Exact Match belongs where a validated configuration must not drift, such as regulated or safety-adjacent systems where any revision change requires formal review anyway. Disabling keying to make a fault go away is almost always the wrong move, because it removes the protection rather than addressing the mismatch. The procedure for applying these settings is covered in setting electronic keying on an EtherNet/IP device.
Frequently Asked Questions
What is the difference between Exact Match and Compatible Module keying?
Exact Match requires the device's vendor, product code, and both major and minor revision to match the configuration exactly, so any firmware change breaks the connection until reconfigured. Compatible Module fixes the vendor and product code but lets the device accept a revision it declares compatible, so a minor firmware upgrade within the compatible family still connects. Compatible Module is the common working setting.
Why do I get a keying mismatch after a firmware update?
Because the update changed the device's revision, and an Exact Match keyed connection requires the revision to match the configuration exactly. The device is correct but its new revision no longer matches what the controller expects. Update the configuration to the new revision, or relax the keying to Compatible Module so in-family firmware changes are tolerated without reconfiguring.
Is it safe to disable electronic keying?
Only as a deliberate, documented exception. Disabling keying lets a connection open regardless of what device is present, which removes the protection against installing the wrong model - exactly what keying exists to prevent. If a keying fault appears, address the mismatch (correct part, or update the expected revision) rather than disabling the check to silence it.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.