Every CIP device has one. Every browse of an EtherNet/IP network reads from it. Every Forward_Open validates against it. Every “what is this device” query touches it. The Identity Object (Class 0x01) is the most-accessed object on every CIP device — yet most articles barely cover it. This article fixes that.
If you have ever wondered where Studio 5000 gets the device name, vendor, firmware revision, and serial number displayed in its hardware browser — it all comes from the Identity Object. If you have ever read about electronic keying in Forward_Open — those values live in the Identity Object. If you have ever rebooted a remote device with a “Reset” command — that command lands on the Identity Object.
This article explains the Identity Object from ODVA’s CIP Networks Library Volume 1, Section 5-2. For broader CIP context, see the CIP Protocol Complete Guide and the CIP Object Model Explained article.
Table of Contents
What the Identity Object is in one paragraph
The Identity Object (Class Code 0x01) is the CIP object that provides identification and general information about a device. Per Volume 1 Section 5-2, the Identity Object must be present in all CIP products — it is the only object class that is mandatory across every device, every vendor, every CIP network. Its instance 1 holds the device’s vendor ID, device type, product code, firmware revision, current status, serial number, and product name. These attributes are what configuration tools read to identify devices, what electronic keying validates in Forward_Open requests, and what ListIdentity discovery broadcasts return.
The mandatory presence rule
This is worth pausing on. Most CIP objects are optional — devices implement them based on their function. A simple discrete I/O block does not need a Motor Data Object. A drive does not need a Discrete Output Point Object. Object inclusion is largely up to the device’s job.
The Identity Object is the exception. ODVA’s specification says: “The Identity Object shall be present in all CIP products.” No CIP device exists without one. Some autonomous devices use multiple instances (one per subcomponent), but every CIP device has at minimum Instance 1.
This universality is why the Identity Object is so important. Any application that needs to identify any CIP device starts by reading Class 0x01, Instance 1.
The required instance attributes (1-7)
The Identity Object Instance 1 has seven required attributes that every CIP device must implement. From Volume 1 Table 5-2.2:
| Attr ID | Access | Name | Type | Purpose |
|---|---|---|---|---|
| 1 | Get | Vendor ID | UINT | Manufacturer identifier assigned by ODVA |
| 2 | Get | Device Type | UINT | Device profile code |
| 3 | Get | Product Code | UINT | Vendor’s product identifier |
| 4 | Get | Revision | STRUCT (USINT, USINT) | Major and Minor firmware revision |
| 5 | Get | Status | WORD | Summary status flags |
| 6 | Get | Serial Number | UDINT | Device’s unique serial number |
| 7 | Get | Product Name | SHORT_STRING | Human-readable device name |
All seven are Get-only — the device sets these at the factory and they cannot be modified at runtime. (The exception is some attributes within Status, which the device updates dynamically based on its operating state.)
Attribute 1 — Vendor ID
A UINT assigned by ODVA when a manufacturer joins as a member. Value 0 is invalid. Some common ones:
| Vendor ID | Manufacturer |
|---|---|
| 1 | Rockwell Automation / Allen-Bradley |
| 8 | Molex |
| 26 | Beckhoff Automation |
| 47 | Omron |
| 49 | Endress+Hauser |
| 87 | Phoenix Contact |
| 110 | Schneider Electric |
| 187 | Festo |
| 243 | (various Schneider divisions) |
| 256 | Schmersal |
| 271 | Bosch Rexroth |
| 759 | Sick AG |
| 1004 | HMS Networks |
ODVA maintains the complete list. New vendor IDs are issued continuously as new companies join ODVA. The Vendor ID combined with the Product Code uniquely identifies any product on any CIP network.
Attribute 2 — Device Type
A UINT identifying the device profile the product implements. Common values:
| Device Type | Profile |
|---|---|
| 0x02 | AC Drive |
| 0x07 | General Purpose Discrete I/O |
| 0x09 | Resolver |
| 0x0A | General Purpose Analog I/O |
| 0x0C | Communications Adapter |
| 0x0D | Servo Drive |
| 0x12 | DC Drive |
| 0x16 | Limit Switch |
| 0x17 | Inductive Proximity Switch |
| 0x18 | Photoelectric Sensor |
| 0x1A | Generic Encoder |
| 0x1B | Mass Flow Controller |
| 0x1F | Pneumatic Valves |
| 0x22 | Generic Device |
| 0x24 | DC Power Generator |
| 0x25 | RF Power Generator |
| 0x26 | Turbine Flow Meter |
| 0x27 | Position Sensor |
| 0x29 | Process Control Valve |
| 0x2B | Generic Device |
| 0x32 | ControlNet PLC |
| 0x33 | EtherNet/IP PLC |
Device profiles define minimum requirements (which objects must exist, which attributes must be set) plus common optional behaviors. A device declaring Device Type 0x02 (AC Drive) must implement the AC Drive Profile from Volume 1 Chapter 6.
Attribute 3 — Product Code
A vendor-assigned UINT that identifies a specific product within a device type. Each vendor assigns this code to each of its products. The Product Code typically maps to one or more catalog/model numbers.
Per the spec: “Products shall have different codes if their configuration and/or runtime options are different. Such devices present a different logical view to the network.”
The value 0 is invalid. The Product Code is the most product-specific identifier — two devices from the same vendor with different functions have different Product Codes.
Attribute 4 — Revision
A STRUCT of two USINTs: Major Revision and Minor Revision. Typically displayed as major.minor. Per the spec:
- The Major Revision is limited to 7 bits (range 1-127). The eighth bit is reserved.
- The Minor Revision is displayed with leading zeros (e.g., 4.001, not 4.1).
- Major revision should be incremented when there is a significant change to fit, form, or function of the product. Changes that affect EDS content require incrementing Major.
- Minor revision is for changes that don’t affect user configuration — bug fixes, hardware component swaps, label changes. Configuration tools do not use minor revision differences to reject EDS files.
This is what electronic keying validates. A Forward_Open Connection Path’s electronic keying segment specifies a Major and Minor Revision; the target compares against its Identity Object Attribute 4 and rejects with Extended Status 0x0116 (Revision mismatch) if they do not match.
Attribute 5 — Status
A 16-bit WORD with bit-level definitions documenting the device’s overall health. We cover this in detail below.
Attribute 6 — Serial Number
A UDINT used in conjunction with the Vendor ID to form a unique identifier for every device on any CIP network. Each vendor is responsible for guaranteeing serial number uniqueness across all its devices. The combination (Vendor ID + Serial Number) uniquely identifies any physical device, ever.
This combination also appears in Forward_Open as the Originator Vendor ID + Originator Serial Number, identifying which scanner is opening the connection.
Attribute 7 — Product Name
A SHORT_STRING (USINT length prefix + ISO-8859-1 characters) up to 32 characters with a human-readable product description. This is the name Studio 5000 and other tools display — “1734-AENT,” “PowerFlex 525-AENETR,” “Kinetix 5500.”
The same Product Code can have multiple Product Names across firmware revisions (vendors sometimes refresh the marketing name without changing the Product Code).
The Status WORD — bit-by-bit
Attribute 5 is the most-read attribute on most CIP devices because it tells you whether the device is healthy. Per Volume 1 Table 5-2.3:
| Bit(s) | Name | Meaning |
|---|---|---|
| 0 | Owned | TRUE = device has an owner (master) |
| 1 | Reserved | Must be 0 |
| 2 | Configured | TRUE = device has been configured beyond out-of-box defaults |
| 3 | Reserved | Must be 0 |
| 4-7 | Extended Device Status | 4-bit enum (see below) |
| 8 | Minor Recoverable Fault | TRUE = recoverable problem detected (no state change) |
| 9 | Minor Unrecoverable Fault | TRUE = unrecoverable problem (no state change) |
| 10 | Major Recoverable Fault | TRUE = device entered Major Recoverable Fault state |
| 11 | Major Unrecoverable Fault | TRUE = device entered Major Unrecoverable Fault state |
| 12-15 | Reserved | Must be 0 |
The fault bits give you a quick health summary:
- Bit 8 set = something is wrong but the device keeps working (e.g., analog input out of range)
- Bit 9 set = something is wrong, the device keeps working, but you must take action (e.g., battery needs replacement)
- Bit 10 set = device has stopped due to a fault that may be recoverable with reset (e.g., configuration incorrect)
- Bit 11 set = device has stopped due to an unrecoverable fault (e.g., ROM checksum failed)
Extended Device Status (bits 4-7)
A 4-bit enum providing more detail on the device’s current condition. Per Volume 1 Table 5-2.4:
| Value | Meaning |
|---|---|
| 0000 | Self-Testing or Unknown |
| 0001 | Firmware Update in Progress |
| 0010 | At least one faulted I/O connection |
| 0011 | No I/O connections established |
| 0100 | Non-Volatile Configuration bad |
| 0101 | Major Fault (bit 10 or 11 is true) |
| 0110 | At least one I/O connection in run mode |
| 0111 | At least one I/O connection established, all in idle mode |
| 1000 | Reserved |
| 1010-1111 | Vendor/Product specific |
The “Connection in run mode” (0110) and “Connection in idle mode” (0111) values are what tell you whether the device is actively running. A healthy I/O block with an active PLC connection reports 0110 in this nibble.
Optional attributes (8-17)
Beyond the mandatory 1-7, devices may implement optional attributes. The most useful ones:
Attribute 8 — State
A USINT enum representing the device’s overall state. Per Volume 1 Table 5-2.2:
| Value | State |
|---|---|
| 0 | Nonexistent |
| 1 | Device Self-Testing |
| 2 | Standby |
| 3 | Operational |
| 4 | Major Recoverable Fault |
| 5 | Major Unrecoverable Fault |
| 6-254 | Reserved |
| 255 | Default for Get_Attributes_All service |
A device returning State = 3 is operational. Anything else needs investigation. State 4 means the device is faulted but might recover (try a Reset). State 5 means hardware failure — power-cycle or replace.
Note: Major Unrecoverable Faults can be so severe that the State attribute may not accurately reflect them — the device may not respond at all.
Attribute 9 — Configuration Consistency Value
A UINT that changes whenever the device’s non-volatile configuration changes. Used as a CRC, incrementing counter, or any other mechanism — the only requirement is that it differs whenever configuration differs. Some scanners check this against a stored value to detect uncommanded configuration drift.
Attribute 10 — Heartbeat Interval
A USINT giving the nominal interval (in seconds) between heartbeat messages. Default is 0, which disables heartbeats. Some devices use heartbeats as a low-overhead “alive” signal independent of cyclic I/O.
Attributes 11-13 — Language attributes
For internationalization. Attribute 11 (Active Language) and Attribute 12 (Supported Language List) work together with the STRINGI data type to expose multi-language product information. Attribute 13 (International Product Name) is the Product Name in all supported languages.
Attributes 15-17 — User-assigned strings
- Attribute 15: Assigned_Name — STRINGI for a user-assigned device name (different from the factory ProdName)
- Attribute 16: Assigned_Description — STRINGI for a user-assigned description
- Attribute 17: Geographic_Location — STRINGI for the physical location of the device
These allow operators to label devices (“Pump Station 3 East Mixer”) in the device itself, surviving power cycles and configuration changes. Not all devices support these — but when supported, they make plant-wide identification much easier.
Attribute 18 — Modbus Identity Info
Conditional. Only present on devices that bridge Modbus to CIP per Volume 7. If the device is not a Modbus device, this attribute is not allowed.
Services supported
Per Volume 1 Table 5-2.6, the Identity Object supports these services:
| Service | Code | Need | Purpose |
|---|---|---|---|
| Get_Attribute_Single | 0x0E | Required (Instance) | Read one attribute |
| Reset | 0x05 | Required (Instance) | Reboot the device |
| Get_Attributes_All | 0x01 | Conditional | Read all attributes in one transaction |
| Set_Attribute_Single | 0x10 | Conditional | Write attribute (required if Heartbeat is implemented) |
| Find_Next_Object_Instance | 0x11 | Optional (Class) | Find next Identity Object instance |
| Get_Member | 0x18 | Conditional | Get member of structured attribute (required for STRINGI) |
For broader service code coverage, see our CIP Service Codes Complete Reference.
The Reset service — how you reboot a device
The Reset service (code 0x05) on the Identity Object is one of the most-used commands in CIP. Issued to Class 0x01, Instance 1, Service 0x05 — it reboots the device.
The Reset service takes one optional parameter — the Reset Type USINT. Per Volume 1 Table 5-2.8:
| Value | Reset Type |
|---|---|
| 0 | Emulate cycling power (default if no parameter) |
| 1 | Return to factory default configuration, then emulate cycling power |
| 2 | Return to out-of-box configuration except communication parameters, then emulate cycling power |
| 3-99 | Reserved by CIP |
| 100-199 | Vendor-specific |
| 200-255 | Reserved by CIP |
Reset Type 0 is what engineers almost always want — “reboot the device but keep my configuration.” Reset Type 1 is the nuclear option — “factory reset and reboot.” Reset Type 2 is the helpful middle ground that wipes application config but keeps network settings (so you don’t lose connectivity to the device after reset).
Per the spec, the device must:
- Determine if it can provide the requested reset type
- Respond to the request (with success or error)
- Attempt to perform the reset
The critical part is step 2 — the device sends the reply before rebooting. This means a successful Reset request returns a normal response, and only then does the device disappear from the network as it cycles power. This is why some tools show “Reset successful” followed immediately by “Device not responding” — both messages are accurate.
Get_Attributes_All on the Identity Object
The Get_Attributes_All service (0x01) on the Identity Object is the workhorse of device discovery. It returns the full identity in one transaction. Per Volume 1 Table 5-2.10, the response layout (byte by byte):
| Byte | Content |
|---|---|
| 0-1 | Vendor ID (little-endian UINT) |
| 2-3 | Device Type (little-endian UINT) |
| 4-5 | Product Code (little-endian UINT) |
| 6 | Major Revision |
| 7 | Minor Revision |
| 8-9 | Status (little-endian WORD) |
| 10-13 | Serial Number (little-endian UDINT) |
| 14 | Product Name length (n) |
| 15 to (14+n) | Product Name characters |
| (15+n) | State (default 255) |
| (16+n) | Configuration Consistency Value |
| (18+n) | Heartbeat Interval |
| (19+n) | Active Language fields |
| Variable | Supported Language List (if implemented) |
| Variable | International Product Name (if implemented) |
This is precisely the data ListIdentity (the UDP broadcast discovery service) returns — see our EtherNet/IP Encapsulation Protocol Explained article for how ListIdentity wraps this in an encapsulation message.
When you call Get_Attributes_All, you get the complete device fingerprint in one round-trip. Configuration tools use this as the first read against any new device — it populates the entire “device info” view at once.
Electronic keying — how the Identity Object validates Forward_Open
Electronic keying is the mechanism that says “the device I’m talking to must match the configuration I expect.” It is built into Forward_Open via the Connection Path’s Electronic Keying Segment.
The keying check compares four values:
- Vendor ID (from Identity Object Attribute 1)
- Device Type (Attribute 2)
- Product Code (Attribute 3)
- Revision (Attribute 4 — Major and Minor)
If any of these doesn’t match what the Forward_Open expects, the connection is rejected with General Status 0x01 and a specific Extended Status:
| Extended Status | Meaning |
|---|---|
| 0x0114 | Vendor ID or Product Code mismatch |
| 0x0115 | Device Type mismatch |
| 0x0116 | Revision mismatch |
This is why electronic keying issues are an Identity Object issue — you can troubleshoot them by simply reading the device’s Identity Object via Get_Attribute_Single and comparing against your configuration. For more on Forward_Open mechanics, see our CIP Forward_Open Service Explained article.
How the EDS [Device] section maps to the Identity Object
The Identity Object is what the EDS file’s [Device] section documents. Each EDS keyword maps to an Identity Object attribute:
| EDS keyword | Identity Object attribute |
|---|---|
VendCode | Attribute 1 (Vendor ID) |
ProdType | Attribute 2 (Device Type) |
ProdCode | Attribute 3 (Product Code) |
MajRev | Attribute 4 — Major Revision |
MinRev | Attribute 4 — Minor Revision |
ProdName | Attribute 7 (Product Name) |
When you import an EDS into Studio 5000 and add the module, the values from the EDS’s [Device] section become the electronic keying values for any Forward_Open the tool generates. The tool reads the device’s actual Identity Object at runtime to compare against the configured values.
See our EDS Files Explained article for the full EDS format.
ListIdentity — the discovery side
The ListIdentity command (EtherNet/IP encapsulation command 0x0063) is a UDP broadcast that returns Identity Object data from every device on a network. Configuration tools like Studio 5000 use this for “browse the network” functionality.
When a device receives a ListIdentity broadcast, it responds with a Common Packet Format containing an Identity Item (type 0x000C). The Identity Item carries:
- Encapsulation Protocol Version
- Socket Address (IP, port)
- Vendor ID
- Device Type
- Product Code
- Revision
- Status (Identity Object Attribute 5)
- Serial Number
- Product Name (Identity Object Attribute 7)
- State (Identity Object Attribute 8)
This is essentially a pre-formatted Get_Attributes_All response that ships back as a UDP broadcast reply. See EtherNet/IP Encapsulation Protocol Explained for the full ListIdentity mechanics.
Reading the Identity Object in practice
Reading a single attribute
Service: 0x0E (Get_Attribute_Single)
Path: Class 0x01, Instance 1, Attribute 7Returns the Product Name. Useful for quick “what is this device?” queries.
Reading everything in one transaction
Service: 0x01 (Get_Attributes_All)
Path: Class 0x01, Instance 1Returns the full identity in one shot. The standard approach for device discovery and inventory.
Rebooting the device
Service: 0x05 (Reset)
Path: Class 0x01, Instance 1
Data: 0x00 (Reset Type 0 — cycle power)Reboots the device while preserving its configuration.
Factory-resetting the device
Service: 0x05 (Reset)
Path: Class 0x01, Instance 1
Data: 0x01 (Reset Type 1 — factory default + reboot)Wipes configuration and reboots. Use carefully.
Common Identity Object errors
| Symptom | Likely cause | What to check |
|---|---|---|
| Get_Attribute_Single returns 0x14 | Attribute not implemented on this device | Optional attributes (8-17) may not exist; required ones (1-7) always do |
| Reset returns 0x10 (Device state conflict) | Device cannot reset from current state | Try again after clearing faults, or use a different Reset Type |
| ListIdentity returns no response from a known device | Device not implementing ListIdentity properly | Some legacy or minimalist devices skip ListIdentity — try direct TCP Get_Attribute_Single |
| Vendor ID returns 0 | Spec violation by the device | Vendor ID = 0 is invalid — contact the manufacturer |
| Product Name shows wrong device | Device firmware was updated but EDS not refreshed | Re-read Identity Object; match EDS to new firmware revision |
| Status WORD shows Major Recoverable Fault (bit 10) | Device entered fault state | Read fault history attributes (object-specific) to find root cause |
| Status WORD changes unexpectedly | Device’s state is changing in real-time | This is normal behavior — Status reflects current state |
For broader CIP error code coverage, see our CIP General Status Codes Reference.
Reading Identity Object traffic in Wireshark
Useful filters when troubleshooting:
cip # All CIP traffic
cip.class == 0x01 # All Identity Object access
cip.class == 0x01 && cip.service == 0x0E # Identity Object reads
cip.class == 0x01 && cip.service == 0x05 # Identity Object resets
enip.command == 0x0063 # ListIdentity broadcasts
enip.command == 0x0063 && enip.identity # ListIdentity responses with Identity dataA productive workflow when debugging device identification issues:
- Filter
cip.class == 0x01to see all Identity Object reads - Find the Get_Attribute_Single or Get_Attributes_All for the device in question
- Decode the response — Wireshark shows Vendor ID, Product Code, Revision, etc. natively
- Compare against your expected values
For broader Wireshark workflows, see our Wireshark for EtherNet/IP guide.
Frequently asked questions
What is the CIP Identity Object?
The CIP Identity Object (Class Code 0x01) is the standardized object that provides identification and general information about a CIP device. It must be present in every CIP device — making it the only universally mandatory object in the CIP specification. Its required attributes include Vendor ID, Device Type, Product Code, Revision, Status, Serial Number, and Product Name.
What is the class code for the CIP Identity Object?
The class code is 0x01 (decimal 1). It is the first defined class in the CIP Object Library and the only one required on every CIP device. Defined in ODVA’s CIP Networks Library Volume 1, Section 5-2.
What attributes does the Identity Object have?
The Identity Object has 18 defined attributes. Attributes 1-7 are required on every CIP device: Vendor ID, Device Type, Product Code, Revision, Status, Serial Number, Product Name. Attributes 8-17 are optional: State, Configuration Consistency Value, Heartbeat Interval, language attributes, Semaphore, Assigned_Name, Assigned_Description, Geographic_Location. Attribute 18 is conditional and only present on Modbus-bridging devices.
How do I reset a CIP device?
Use the Reset service (code 0x05) on the Identity Object Instance 1. The service takes an optional USINT parameter: 0 = cycle power (preserves configuration), 1 = factory default + cycle power (wipes config), 2 = out-of-box config except network settings + cycle power (resets app config but keeps connectivity). The device responds before rebooting, so you get a success acknowledgment immediately followed by the device disappearing from the network.
What is Vendor ID in the CIP Identity Object?
Vendor ID is a UINT (Attribute 1) assigned by ODVA when a manufacturer becomes a member. Each manufacturer has a unique Vendor ID. Common examples: Rockwell Automation = 1, Beckhoff = 26, Omron = 47, Phoenix Contact = 87, Schneider Electric = 110. The Vendor ID combined with Product Code uniquely identifies any product on any CIP network.
What is the Status attribute in the CIP Identity Object?
Status (Attribute 5) is a 16-bit WORD with bit-level definitions documenting the device’s overall health. Bit 0 is Owned (master connected), bit 2 is Configured (non-default config), bits 4-7 are Extended Device Status (4-bit enum), bits 8-11 are fault flags (Minor Recoverable, Minor Unrecoverable, Major Recoverable, Major Unrecoverable). Reading this attribute gives a quick snapshot of device health.
What is electronic keying in CIP?
Electronic keying is the mechanism that validates a connection target matches the configured device. It compares four Identity Object values: Vendor ID, Device Type, Product Code, and Revision. Forward_Open’s Connection Path includes an Electronic Keying Segment with these values; the target compares them against its own Identity Object and rejects the connection if any value mismatches (Extended Status 0x0114, 0x0115, or 0x0116).
What is the difference between Major and Minor Revision?
Major Revision (USINT in Attribute 4) increments when there is a significant change to the product’s fit, form, or function — particularly any change that affects the EDS file. Minor Revision (USINT in Attribute 4) increments for changes that don’t affect user configuration: bug fixes, hardware component swaps, label updates. Electronic keying checks major revision strictly; minor revisions are typically treated more loosely.
What does Reset Type 0 vs 1 vs 2 do?
Reset Type 0 emulates cycling power — the device reboots but preserves all configuration. Reset Type 1 returns the device to factory defaults, then cycles power — wiping all configuration including network settings. Reset Type 2 returns to factory defaults except communication link parameters, then cycles power — keeping the IP address, subnet mask, etc. so you don’t lose connectivity. Type 0 is the safest for most operations; Type 2 is useful when you want to clear application config without losing network access.
How does the EDS [Device] section relate to the Identity Object?
The EDS file’s [Device] section documents the values that should be in the device’s Identity Object. EDS keywords map to Identity attributes: VendCode → Attribute 1 (Vendor ID), ProdType → Attribute 2 (Device Type), ProdCode → Attribute 3 (Product Code), MajRev/MinRev → Attribute 4 (Revision), ProdName → Attribute 7 (Product Name). The EDS provides this information offline; the device’s actual Identity Object provides it at runtime. Electronic keying compares the two.
Can the Identity Object Product Name be changed?
The factory Product Name (Attribute 7) is read-only and set by the manufacturer. However, devices may implement optional Attribute 15 (Assigned_Name) which is settable — this allows users to assign their own name to a device that survives power cycles. Not all devices implement Attribute 15; check the device’s EDS or documentation.
Where can I find the official CIP Identity Object specification?
The Identity Object is defined in ODVA’s CIP Networks Library Volume 1: Common Industrial Protocol (CIP) Specification, Chapter 5 (Object Library), Section 5-2. The current edition is 3.3 (2007). ODVA members can access the full specification at odva.org. The mandatory presence rule, attribute definitions, Status WORD bit layout, and Reset service parameters are all documented there.