What Is the CIP Identity Object?
When a browse tool lists an EtherNet/IP device by name, vendor, and revision, it is reading one object: the Identity object. It is the first object any CIP device must implement and the one that makes electronic keying, firmware checks, and device inventory possible. This page explains what the Identity object holds, why class code 0x01 is worth memorizing, and how its attributes drive the keying decision when a controller connects.
CIP Identity Object in one line: The CIP Identity object is class code 0x01, the mandatory object that names a device: vendor ID, device type, product code, revision, serial number, product name, and a status word. Browse tools, firmware inventory, and electronic keying all read this object to identify exactly what is on the network before any I/O connection opens.
What the Identity Object Holds
The Identity object is class 0x01, instance 1, and its attributes are standardized so any tool can read them the same way across vendors. Attribute 1 is the vendor ID, a number ODVA assigns to each member so that product codes never collide between manufacturers. Attribute 2 is the device type, which says what category of device this is - a communications adapter, a drive, an I/O block. Attribute 3 is the product code, the manufacturer's own catalog identifier for the specific model. Attribute 4 is the revision, split into major and minor, which is what firmware-sensitive logic checks.
Attribute 5 is a status word with bits for owned, configured, and various fault and self-test conditions - it is a compact health summary readable without touching any other object. Attribute 6 is the serial number, unique within a vendor ID, useful for asset tracking. Attribute 7 is the product name as a human-readable string. Together these seven attributes are a complete nameplate: read them and you know the vendor, the model, the firmware revision, and the current health of the device.
The Identity object also supports a Reset service, which is how a tool commands a device to restart - either a normal reset or, on devices that support it, a reset to out-of-box defaults. That single service is why a browse tool can offer a reset button without any device-specific driver.
How Identity Drives Electronic Keying
The Identity attributes are exactly the fields an EtherNet/IP connection request carries for keying. When a controller opens a connection, it can include the expected vendor ID, device type, product code, and revision, and the device compares those against its own Identity object before accepting. If the controller expected a specific model at a specific revision and finds something different, the connection is refused with a keying error. This is the mechanism that stops a replacement device of the wrong type or wrong firmware from silently taking over a slot.
Understanding that keying reads the Identity object explains the failure modes directly. A keying mismatch after a firmware update is the revision attribute disagreeing; a mismatch after a hardware swap is usually the product code disagreeing. The fix is either to install the matching device or to relax the keying setting, and the trade-offs of that choice are covered in CIP electronic keying. The Identity object is simply the source of truth the keying check consults.
Identity in Commissioning and Diagnostics
During commissioning the Identity object is the first thing you confirm. Reading it verifies you are talking to the device you think you are, at the firmware you expect, before you invest time in configuring assemblies and connections. A mismatch caught here - wrong product code, unexpected revision - saves hours of chasing symptoms that trace back to the wrong hardware in the rack. The EtherNet/IP connection timeout guide starts many diagnostics with this same identity confirmation.
For ongoing operation, the status word in the Identity object gives a cheap health signal, and the vendor ID plus product code plus serial number form a stable asset key for inventory. When a controller has read these into named tags, a monitoring platform such as Merobix can trend and alarm on the derived health and firmware-revision tags the controller exposes; it does not itself poll the raw Identity object. The controller owns the CIP conversation, and the identity data it surfaces becomes ordinary tags for the SCADA layer.
Frequently Asked Questions
What class code is the CIP Identity object?
Class code 0x01. It is the first mandatory object in every CIP device, so a request to class 1, instance 1 reads the device's nameplate: vendor ID, device type, product code, revision, serial number, product name, and status. Because the class code and attribute IDs are standardized, one tool reads them identically across every vendor's EtherNet/IP and DeviceNet hardware.
What information is in the Identity object?
Vendor ID (who made it), device type (what category), product code (which model), revision (major and minor firmware), a status word (health bits), serial number (unique per vendor), and product name (a readable string). These attributes are the fields electronic keying compares when a controller opens a connection, and the fields a browse tool shows when it lists devices.
Why does firmware revision matter in the Identity object?
Because electronic keying can require a matching revision. The connection request carries the expected major and minor revision, and the device compares them against its Identity object. If a firmware update changed the revision, an Exact-Match keyed connection is refused until the controller configuration is updated to expect the new revision or the keying is relaxed to a less strict setting.
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.