PROFINET Explained: Real-Time Classes, DCP and PROFINET Security

PROFINET is the industrial Ethernet protocol maintained by PROFIBUS and PROFINET International (PI) and standardised as Type 10 in IEC 61158 with its profiles in IEC 61784. A controller exchanges cyclic I/O data with field devices directly over Ethernet frames (RT), with scheduled isochronous traffic (IRT) for motion and TSN as the newer Layer 2 option. Classic PROFINET has no built-in authentication, so devices can be renamed and readdressed by anyone on the segment through DCP; PI's Security Classes 1 to 3 add read-only DCP, signed device descriptions and, in Classes 2 and 3, cryptographic integrity, authenticity and confidentiality.

This post sits beside our other one protocol per post explainers for operational technology: Modbus, EtherCAT, OPC UA, DNP3 and BACnet. Here we stay on PROFINET: the device model, the real-time classes, DCP at frame level, the security classes as PI defines them, and a passive capture workflow.

Safety note before anything else. PROFINET networks drive conveyors, presses, robots, pumps, valves and drives. Frames on that wire move physical machinery, and a renamed device, a changed IP address or a second controller can stop a line, drop a safety function into its safe state or move an actuator without warning. Everything hands on in this post is either strictly passive (listening on a mirror port that cannot transmit) or belongs on an isolated lab rig with its own controller, a few lab I/O devices and no connection to any production segment. Never connect a laptop, a capture tool or an engineering tool to a running plant network without written approval from the people responsible for that machine and its safety case.

Key takeaways

• PROFINET is maintained by PROFIBUS and PROFINET International (PI) and specified in IEC 61158-5-10 (services), IEC 61158-6-10 (protocol), IEC 61784-2-3 (profiles) and, from V2.5, the security profile IEC 61784-6-3.
• An IO controller (usually a PLC) exchanges cyclic data with IO devices; IO supervisors are engineering and diagnostic tools. A GSDML file, an XML device description, tells the engineering tool what each device type can do.
• Real-time frames and DCP use EtherType 0x8892 directly on Ethernet. Connection setup and records use UDP (34964 for the IO context manager).
• RT uses standard switches with VLAN priority; IRT reserves scheduled time slots for motion control, down to 31.25 µs cycles per PI. TSN arrived with specification V2.4, and IEC/IEEE 60802 was published on 29 June 2026.
• DCP names and addresses devices with Identify, Hello, Get and Set. In classic PROFINET any station on the segment can send a DCP Set.
• PI's Security Classes: Class 1 (robustness) adds signed GSDX files, SNMP access control and read-only DCP; Class 2 adds certificate based authentication and cryptographic integrity; Class 3 adds confidentiality.
• Architecture still comes first: cells as ISA/IEC 62443 zones, controlled conduits, no laptops bridging IT and OT, restricted DCP Set, a firmware inventory and passive monitoring.

What PROFINET is, who maintains it and where it is standardised

PROFIBUS and PROFINET International

PROFINET comes from the same community as PROFIBUS, the serial fieldbus that is still common in process plants. The umbrella organisation is PROFIBUS and PROFINET International (PI). Its German association, PROFIBUS Nutzerorganisation e.V. (PNO) in Karlsruhe, publishes the specifications, runs the certification office and operates a Cyber Security Incident Response Team (PI-CSIRT) on behalf of PI. PI describes itself as supporting its technologies "since 1989" and counts about 1,800 member companies across more than 25 regional PI associations.

This matters for security. The PI-CSIRT says its focus is weaknesses in the specifications, while product specific weaknesses are the responsibility of the supplier. When a PROFINET device has a vulnerability, the fix comes from the device maker, not from PI.

IEC 61158 and IEC 61784

In IEC terms PROFINET is the "Type 10" fieldbus in IEC 61158, with profiles in Communication Profile Family 3 (CPF 3) of IEC 61784. PI's specification page maps its documents to the IEC parts:

PI states that PROFINET V2.4MU3 is specified in IEC 61158-6-10:2023, IEC 61158-5-10:2023 and IEC 61784-2-3:2023. The British Standards Institution catalogue lists IEC 61784-2-3:2023, "Additional real-time fieldbus profiles based on ISO/IEC/IEEE 8802-3. CPF 3", as published on 30 March 2023. PROFINET V2.5, which PI lists in its download area with a July 2026 date, references committee drafts (CD) of the next editions: CD IEC 61158-5-10, CD IEC 61158-6-10, CD IEC 61784-2-3 and the new CD IEC 61784-6-3. In other words, the security profile exists in PI's specification today and is on its way through the IEC process.

The safety profile, PROFIsafe, treats PROFINET as a "black channel" and checks safety data end to end, per PI. That protects against random faults, not a deliberate attacker.

A dated timeline

The PROFINET IO device model

IO controller, IO device and IO supervisor

PROFINET IO borrows the PROFIBUS mental model and moves it onto Ethernet:

• IO controller. Usually a PLC or a PC based controller. It holds the configuration of the I/O system, establishes connections to devices at startup and exchanges cyclic process data with them. One controller typically owns many devices.
• IO device. A distributed field device: a remote I/O station, a drive, a valve terminal, a gateway to a serial fieldbus, a sensor or an Ethernet-APL field instrument in a process plant. Devices are modular. A device has slots, and each slot holds a module with subslots that carry the actual I/O channels.
• IO supervisor. An engineering tool, an HMI or a diagnostic station that connects to devices for commissioning, parameter reads and troubleshooting, usually without owning the cyclic I/O.

The logical link between a controller and a device is an Application Relation (AR). Inside an AR sit Communication Relations (CRs) for input data, output data and alarms. The CISA Zeek parser for PROFINET IO uses exactly this vocabulary: it logs how the context manager protocol sets up ARs and CRs "between a controller and an I/O device".

How a device joins the network

Startup is where security and safety meet, so it is worth walking through in order:

1. The device powers up with a station name (NameOfStation) stored in non-volatile memory, or with no name if it is fresh from the box.
2. The controller, which knows from its engineering project which names it expects, uses DCP Identify to find a device with the right name. If it is configured to, it uses DCP Set to give that device its IP address, subnet mask and gateway.
3. The controller opens the AR with a connect request over UDP. These context manager messages use DCE/RPC; the CISA parser registers the default server port as 34964/udp.
4. The controller writes parameter records to each submodule, signals that parameterisation is finished, and the device confirms it is ready.
5. Cyclic data starts. From here on, input and output frames flow directly on Ethernet with EtherType 0x8892, each identified by a 16 bit Frame ID, and alarms travel as acyclic real-time frames.

PROFINET also uses LLDP for topology, which lets a replacement device on the same switch port inherit its predecessor's name, a feature PI describes as device replacement "without engineering or memory cards".

GSDML: how a device describes itself

Every PROFINET device type ships with a GSD file. For PROFINET it is written in XML and called GSDML. PI describes the GSD as information about "the basic capabilities of a device": the communication options, the module and submodule catalogue, the available diagnostics, timing limits and identification numbers such as the vendor ID and device ID. PI notes the format should comply with ISO 15745, the base standard for device descriptions, and that it is not meant to describe technological functions or a device user interface (that is the job of other integration technologies).

The engineering tool imports the GSDML file and compiles the project the controller uses to configure the device, so the file is part of the trust chain. A tampered GSDML could change default parameters or timing values that end up in a controller, and until recently nothing proved a file came unmodified from its manufacturer.

PI closed that gap as part of Security Class 1. Since the November 2022 announcement, a manufacturer can sign a GSDML file with an XML signature (W3C, IETF RFC 3275) using the XAdES B-LT extension (ETSI EN 319 132-1). The signature and the GSDML content are packaged in an Open Packaging Convention container (ISO/IEC 29500-2:2021), which is why signed files carry a new extension: GSDX. PI's certification office issues a manufacturer specific certificate valid for three years, and since mid April 2023 a manufacturer can either sign with a smart card and PI's tooling or upload files to PI's signing portal. A signed GSD, in PI's words, ensures "both its authenticity and integrity".

For asset owners: prefer GSDX from the manufacturer, keep every file you imported, and record its version and date next to the device's firmware version.

Communication classes: TCP/IP, RT, IRT and TSN

PROFINET does not use one transport for everything. It picks the transport by how time critical the traffic is.

Non real-time: UDP and TCP/IP

Configuration and acyclic services run over IP. The connect sequence, record reads and writes (parameters, identification and maintenance data, diagnostics) and other context manager traffic travel as DCE/RPC over UDP, which is why the CISA parser watches 34964/udp. Devices may also expose SNMP for network management, a web server or OPC UA. All of this shares the wire with real-time traffic, and PI's overview lists "parallel TCP/IP communication" as one of PROFINET's benefits.

So the plant network carries ordinary IP services next to real-time control frames. PI's overview notes that value added functions such as web services or OPC UA connectivity "could lead to increased direct communication with higher-level systems outside a defined security zone".

RT: real-time on standard Ethernet

PROFINET RT (real-time, also called RT_CLASS_1 in the specification) skips the IP stack. Cyclic frames carry EtherType 0x8892 and a Frame ID, and switches give them priority with IEEE 802.1Q VLAN priority tags. PI describes RT as deterministic, prioritised and cyclic, running on standard Ethernet infrastructure. Each IO device sends its inputs and receives its outputs at a configured update time.

The Wireshark dissector source shows how the Frame ID space is split. A few of the ranges, as the dissector labels them:

Notice the "with security" variants. Current Wireshark versions already decode security metadata fields on RT frames (pn_rt.security_information, pn_rt.security_meta_data), which reflects the protected frame formats introduced by the security extensions.

IRT: isochronous real-time

PROFINET IRT (Isochronous Real-Time, RT_CLASS_3) divides each communication cycle into a reserved, scheduled phase for IRT frames and an open phase for everything else. The switches, which for IRT must be PROFINET IRT capable hardware, are synchronised with PTCP (the precision transparent clock protocol listed on the Wireshark PROFINET wiki) and forward IRT frames on a precomputed schedule, so standard traffic can never block them. PI's IRT page stresses that the data "always arrives on time, without delays or jitter", which is what servo drives and synchronised motion need.

The performance upgrade in specification V2.3 added three mechanisms that PI describes on its overview page:

• Fast forwarding, which reduces forwarding time in each switch, a real gain in long line topologies where a frame passes through many devices.
• Dynamic frame packing, which combines the small I/O payloads of several devices into one frame to cut Ethernet overhead.
• Fragmentation, which splits large non real-time frames into smaller pieces so they cannot hold up the next real-time phase.

With those, PI says, cycle times down to 31.25 µs are possible while standard data keeps flowing in parallel.

TSN: the newer Layer 2 option

Time-Sensitive Networking is a set of IEEE 802.1 standards for bounded latency on standard Ethernet. PI states that "PROFINET specification V2.4 with integrated TSN" has been published and that integrating TSN "as an additional layer 2 technology in the PROFINET architecture has been achieved". The industrial TSN profile itself is IEC/IEEE 60802, a joint project of IEC SC65C/WG18 and IEEE 802; the IEEE 802.1 project page lists it as a published standard, IEC/IEEE 60802-2026, dated 29 June 2026.

PI's argument for TSN is convergence: on a classic network a large TCP/IP transfer, such as a virus scan, can block a real-time frame in a switch queue, while TSN schedules traffic in standard chips. Network configuration also moves into runtime: the user sets a working clock master (typically the PLC), the data rate, a domain name and the update cycles.

TSN does not authenticate anything. It makes networks more converged, which makes the security classes matter more.

Conformance classes

PI certification also groups devices into conformance classes, and PI's V2.5 notes say the security changes "introduce a new class CC-E" that complements the existing ones. When you specify new equipment, ask for the conformance class and the security class separately.

A worked timing example

Illustrative numbers, not any product's limits: suppose an RT cell has a send clock of 1 ms, and a remote I/O station is configured with a reduction ratio of 4. Its update time is then 4 ms: it sends inputs every fourth send clock. If the watchdog factor is 3, the controller tolerates three missed frames, so it declares the device failed after 12 ms of silence and both sides drop outputs to their configured safe values.

If a flood or a blocked port silences that station for 15 ms, its outputs go to safe state and the controller raises a station failure. That is availability loss without any intrusion, which is why PI calls Security Class 1 "robustness" and publishes a netload robustness guideline.

DCP: how devices get names and addresses

What DCP does

DCP, the Discovery and basic Configuration Protocol, is the PROFINET helper protocol for finding devices and setting their identity. It runs directly on Ethernet with EtherType 0x8892, not over IP, so it works before a device has an address and does not cross routers. The Wireshark dissector names four services:

Each request carries a transaction ID (pn_dcp.xid) and a list of option and suboption blocks. The suboptions you will see most often in a capture are the station name (pn_dcp.suboption_device_nameofstation), the IP address, mask and gateway (pn_dcp.suboption_ip_ip, pn_dcp.suboption_ip_subnetmask, pn_dcp.suboption_ip_standard_gateway), the vendor and device IDs, the device role and the control suboption that carries actions such as signalling (blinking a device LED so a technician can find it) and resetting parameters.

Why DCP is unauthenticated

Classic DCP has no notion of who is allowed to ask. A device answers Identify from anyone on the Layer 2 segment, and it accepts Set from anyone too. That was a deliberate design choice for commissioning on an isolated cell: a technician plugs a laptop into a switch, finds new devices, names them, and the controller takes over. It assumes the cell is physically and logically closed.

On today's networks that assumption often fails. Anyone with Layer 2 access to a cell can read every device's name, type, vendor and address. Anyone who can send a DCP Set can change a station name or IP address, which breaks the controller's AR, sends the device's outputs to safe state and stops that part of the process. No software vulnerability is needed; the protocol is working as specified.

DCP's reach is limited to one broadcast domain. That is the single most useful fact for defenders: if you control which stations share a Layer 2 segment with your devices, you control who can use DCP against them.

What changed: read-only DCP and filtering

PI's 2019 announcement of the Security Classes listed, among the first Class 1 measures, "a read-only function for configuration information such as the device name". PI North America summarises it the same way: Security Class 1 "allows for DCP commands to be set to read-only mode". On devices that support it, once the plant is commissioned, a DCP Set from the network is refused and the name and IP address stay as engineered.

The specification is still adjusting DCP. PI's change notes for V2.4MU4 include "adjustment of the DCP filter chaining function" and a distinction between operational and administrative IP parameters in the DCP service. V2.5 goes further and, in PI's words, replaces "protocols without a secure variant" such as CLRPC and RSI with secure capable successors called SXP over Layer 3 and SXP over Layer 2.

Read-only DCP helps only where firmware supports it and it is switched on, so brownfield plants still need the network controls below.

PROFINET Security Classes 1 to 3

Where they came from

PI's original concept was defence in depth: a multi-level perimeter with firewalls, zones inside the plant, overload testing of devices and organisational measures. PI's overview explains why that no longer suffices: devices talk to higher level systems directly, networks are harder to separate, and one compromised PC inside a cell bypasses the perimeter. So PI added protection inside the cell. Its November 2019 press release says the analysis of security objectives led PI to define "three security classes: robustness, integrity and authenticity, and confidentiality", building on IEC 62443.

What each class adds

The descriptions of Classes 2 and 3 come from PI North America's summary page and PI's own announcements. Class 2 secures "the integrity and authenticity of the assets and the communication relations" with cryptographic functions and protects configuration data. Class 3 includes Class 2 and adds confidentiality for "all services". PI's security page lists research papers behind the design, including a 2021 evaluation of the AES-GCM algorithm used for PROFINET security in cyclic real-time communication and a 2021 paper on rekeying without interrupting cyclic exchanges. PI's V2.4MU5 notes add "Enable RT_CLASS_3 for secure communication", a new symmetric key update, security event logging in a SYSLOG style and a factory reset for the security configuration.

What V2.5 adds

PI's description of V2.5 is the clearest picture of where PROFINET security is now:

• Secure capable successors (SXP over Layer 3 and Layer 2) replace protocols without a secure variant.
• Secure provisioning using IDevIDs (device identities installed by the manufacturer) and certificates, and secure communication using Secure SXP over TCP.
• A new conformance class, CC-E.
• Non-essential protocols, including SNMP, made optional or removable so they can be disabled.
• Legacy functions removed, including FactoryReset, NME and the Netconf section.
• Backward compatibility maintained, so existing systems keep running and can be extended step by step.

PI also published a white paper on how PROFINET can contribute to EU Cyber Resilience Act compliance, which says CRA obligations start "in December 2027" for manufacturers of products with digital elements. And PI says PROFINET security work is aligned with IEC 62443-4-2 in collaboration with an independent testing body.

What the classes do not do

Security classes are device capabilities. They do not segment networks, patch controllers or inventory firmware. Both ends must support a class for it to apply, and Classes 2 and 3 need a certificate lifecycle: issuing, renewal and device replacement at three in the morning.

A note on disputed dates

PI's pages disagree on when the first PROFINET Security Guideline appeared. The 2019 press release says "since 2006"; the security page says the guideline order no. 7.002 "dates November 2013", and the download area now lists version 2.0 dated November 2025. Treat 2006 as PI's claim.

PROFINET in ISA/IEC 62443 and NIST SP 800-82r3

Zones and conduits

ISA/IEC 62443 is the series of standards for security of industrial automation and control systems. ISA's catalogue lists the parts a PROFINET plant uses most: 62443-2-1 (security program requirements for asset owners, 2024 edition), 62443-3-2 (security risk assessment for system design), 62443-3-3 (system security requirements and security levels), 62443-4-1 (secure product development lifecycle) and 62443-4-2 (technical security requirements for components).

Part 3-2 is where zones and conduits come from. A zone is a group of assets that share security requirements; a conduit is the controlled communication path between zones. Mapped onto PROFINET:

PI's 2022 white paper "OT Security: Classification of IEC 62443" does this mapping formally: it assigns the 62443 parts to operators, integrators and product suppliers and then maps the PROFINET security concept onto them.

NIST SP 800-82 Rev. 3

NIST SP 800-82 Rev. 3, published September 2023, covers OT topologies, threats and countermeasures for "programmable systems and devices that interact with the physical environment". For a PROFINET plant its themes apply directly: segment OT from IT, protect boundaries, control remote access and plan around safety and availability. NIST released the Rev. 4 initial public draft on 21 September 2026 (comments due 30 November 2026), so record which revision you follow.

CISA

CISA's May 2025 fact sheet "Primary Mitigations to Reduce Cyber Threats to Operational Technology" lists measures that read like a PROFINET checklist: remove OT connections to the public internet, change default passwords, secure remote access, "segment IT and OT networks" with a demilitarised zone for passing control data to enterprise systems, and practise operating OT systems manually. CISA also maintains the open source Zeek parser for PROFINET IO used below.

PROFINET compared with EtherNet/IP, EtherCAT and Modbus TCP

Actual use overlaps heavily across industries. Our EtherCAT and Modbus posts go deeper on those two.

Step by step: capture PROFINET safely, document devices and lock down DCP

Read this first. Steps 1 to 4 are passive: you listen on a mirror port and send nothing. Steps 5 and 6 change network or device configuration and must be done first on an isolated lab rig with its own controller and lab I/O devices whose outputs drive nothing or only LEDs, then rolled out to production only through your normal change process with the machine owner's approval and a planned stop. Do not run discovery tools that send DCP Identify on a production network: an Identify is harmless in theory, but every unexpected frame on a cell is a change you did not plan.

Step 1: get a safe capture point

Ask the network or controls team for a SPAN (mirror) port on the cell switch, or a passive network TAP on the controller uplink. A mirror port that copies both directions of the controller's port sees cyclic traffic, alarms, DCP and context manager traffic for that controller. Make sure the mirror port is configured so it cannot transmit into the cell.

On the capture computer, bring the interface up with no IP address and no IPv6, so the laptop says nothing on the wire. Check the interface name first; do not guess:

# List interfaces and confirm which one is cabled to the mirror port
ip -br link
# Bring the capture interface up with no address (replace enx001122334455 with yours)
sudo ip addr flush dev enx001122334455
sudo sysctl -w net.ipv6.conf.enx001122334455.disable_ipv6=1
sudo ip link set enx001122334455 up promisc on
ip -br addr show enx001122334455   # should show UP with no IPv4 or IPv6 address

Step 2: capture with a filter that keeps only PROFINET

Use dumpcap (it ships with Wireshark) with a capture filter so the file holds only what you need. Real-time and DCP traffic is EtherType 0x8892, LLDP is 0x88cc, and context manager traffic is UDP 34964. VLAN tagged frames need the vlan variant too.

sudo dumpcap -i enx001122334455 \
  -f "ether proto 0x8892 or ether proto 0x88cc or udp port 34964 or (vlan and (ether proto 0x8892 or udp port 34964))" \
  -b duration:3600 -b files:24 \
  -w /data/captures/cell07.pcapng

Capture through a full shift and, if possible, a planned restart, because DCP and connect traffic mostly happens at startup.

Step 3: read the capture

Open the files in Wireshark (the display filter reference currently covers versions up to 4.6.9) and use display filters:

pn_dcp                                        all DCP traffic
pn_dcp.service_id == 5 && pn_dcp.service_type == 1   Identify responses
pn_dcp.service_id == 4                        DCP Set requests and responses
pn_dcp.service_id == 6                        Hello announcements at startup
pn_rt                                         real-time frames (cyclic, alarms)
pn_rt.frame_id >= 0x8000 && pn_rt.frame_id <= 0xbfff   RT class 1 cyclic data
pn_io                                         context manager and records
lldp                                          neighbour and port data

For an inventory, pull fields out with tshark:

# One line per device seen answering Identify, or announcing with Hello
tshark -r /data/captures/cell07_00001.pcapng \
  -Y "pn_dcp.suboption_device_nameofstation" \
  -T fields -E separator=, -E header=y \
  -e frame.time -e eth.src \
  -e pn_dcp.service_id -e pn_dcp.service_type \
  -e pn_dcp.suboption_device_nameofstation \
  -e pn_dcp.suboption_ip_ip -e pn_dcp.suboption_vendor_id \
  -e pn_dcp.suboption_device_id -e pn_dcp.suboption_device_role \
  | sort -u > cell07_dcp_inventory.csv

# Every DCP Set in the capture, with who sent it
tshark -r /data/captures/cell07_00001.pcapng -Y "pn_dcp.service_id == 4 && pn_dcp.service_type == 0" \
  -T fields -e frame.time -e eth.src -e eth.dst \
  -e pn_dcp.suboption_device_nameofstation -e pn_dcp.suboption_ip_ip

In normal operation, DCP Set should come only from the controller at startup or an engineering station during a planned change. Any other source deserves a question.

Step 4: add the CISA Zeek parser for ongoing monitoring

For continuous, passive monitoring, CISA's ICSNPP project includes icsnpp-profinet-io-cm, a Zeek plugin written in Spicy that parses PROFINET IO context manager traffic (DCE/RPC over UDP) and writes profinet_io_cm.log. The README documents installation with the Zeek package manager:

zkg refresh
zkg install icsnpp-profinet-io-cm
zeek -NN | grep -i profinet       # expect ANALYZER_SPICY_PROFINET_IO_CM
# Offline analysis of a capture file
zeek -Cr /data/captures/cell07_00001.pcapng
ls profinet_io_cm.log

The parser registers 34964/udp by default and also uses a payload signature to find the protocol on other ports. Alert on new controllers opening ARs, connects outside maintenance windows and records written from unexpected hosts. The parser covers context manager traffic, not DCP, so keep the tshark DCP extraction as a scheduled job.

Step 5: document names, GSDML versions and firmware

Turn the capture into a living record. For each device:

To pull identity data from the GSDML files you already have:

# For every GSDML file in the engineering share, print file name, vendor ID and device ID
for f in /eng/gsd/*.xml; do
  ids=$(xmllint --xpath 'string(//*[local-name()="DeviceIdentity"]/@VendorID)' "$f" 2>/dev/null)
  dev=$(xmllint --xpath 'string(//*[local-name()="DeviceIdentity"]/@DeviceID)' "$f" 2>/dev/null)
  echo "$(basename "$f"),$ids,$dev,$(sha256sum "$f" | cut -d' ' -f1)"
done > gsdml_inventory.csv

The hash shows later whether a file on the share was replaced. For GSDX files, rely on the engineering tool's signature check.

Step 6: segment cells and restrict DCP Set (lab first)

The goal is that only the controller and approved engineering stations can send DCP Set into a cell, and nothing outside the cell can reach it at Layer 2 at all.

1. One cell, one Layer 2 domain. Give each machine or process cell its own VLAN and switch ports. Do not stretch a VLAN across cells or into office areas. Disable unused switch ports and use port security so a new MAC address on an access port is noticed.
2. A cell firewall on the conduit. Route between cells and the supervisory network through a firewall that allows only named IP flows (for example, HMI to controller on the specific protocol the HMI uses, historian to controller for reads). Since DCP and RT are Layer 2, they do not cross this boundary at all.
3. Switch on read-only DCP where devices support it. This is the Security Class 1 control, configured in the engineering tool or the device. Test on the lab rig that the controller can still bring devices up after a power cycle, because some startup flows rely on DCP Set from the controller.
4. Filter DCP Set at the edge of the cell where the switch supports it. Many managed industrial switches can filter by EtherType or protect specific ports. Where a Linux bridge sits in the path in a lab or test setup, an nftables rule in the bridge family can drop DCP Get or Set frames except from the controller's MAC address:

# LAB RIG ONLY. Untagged frames: EtherType at bytes 12 to 13, Frame ID at 14 to 15, service ID at byte 16.
# Replace br0 and the MAC address with your lab values, test, then translate into your switch's own features.
sudo nft add table bridge pnlab
sudo nft add chain bridge pnlab fwd '{ type filter hook forward priority 0; policy accept; }'
sudo nft add rule bridge pnlab fwd ether type 0x8892 @ll,112,16 0xfefd @ll,128,8 0x04 \
  ether saddr != 00:1b:1b:aa:bb:cc counter log prefix \"pn-dcp-set-blocked \" drop
sudo nft list ruleset

VLAN tags shift every offset by four bytes, so test with your lab's tagging. In production, use the switch's own supported features in a maintenance window.

5. Re-run steps 2 and 3 after the change and confirm that DCP Set now comes only from expected sources and every device kept its name and address.

Common mistakes

• Flat plant networks. One VLAN across many cells means any compromised PC anywhere on it can send DCP to every device. It also lets a broadcast storm in one area stop I/O in another. Build one Layer 2 domain per cell.
• Engineering laptops bridging IT and OT. A laptop with Wi-Fi on the office network and a cable in a cell switch is a router you did not design. It carries whatever it picked up elsewhere straight into the zone. Use dedicated engineering stations or a controlled jump host, and disable bridging and dual homing.
• Leaving DCP Set allowed from anywhere. After commissioning, very few stations need to rename or readdress devices. Turn on read-only DCP where supported, filter DCP Set at the cell edge, and log the ones that remain.
• No firmware inventory for IO devices. Plants inventory controllers and forget the dozens of remote I/O stations, drives and gateways, each running firmware with its own advisories. Read I&M data, record firmware, and subscribe to the suppliers' security advisories and PI-CSIRT advisories.
• Treating unsigned GSDML files as trusted. Downloading a device description from a forum or a shared drive with no provenance puts an unverified file into your engineering chain. Prefer GSDX from the manufacturer, keep hashes, and restrict who can write to the engineering share.
• Confusing PROFIsafe with security. PROFIsafe protects against random faults in the black channel. It is not designed to withstand a deliberate attacker, and it is not a reason to skip segmentation.
• Exposing devices directly. Web servers, SNMP and OPC UA endpoints on PROFINET devices should never be reachable from the internet or the office network directly. CISA's first primary mitigation is removing OT connections from the public internet.

FAQ

What is PROFINET in simple terms?

It is how a PLC talks to remote I/O, drives and sensors over Ethernet in real time, maintained by PI and standardised in IEC 61158 and IEC 61784.

What is the difference between PROFINET RT and IRT?

RT uses standard switches and VLAN priority. IRT reserves a scheduled phase in every cycle, needs IRT capable switches, and serves motion control, with cycles down to 31.25 µs per PI.

What is PROFINET DCP used for?

DCP finds PROFINET devices on the local network and sets their station name and IP parameters, using the Identify, Hello, Get and Set services. Controllers use it at startup, and engineers use it during commissioning.

Is PROFINET encrypted?

Classic PROFINET is not encrypted or authenticated. PI's Security Class 2 adds cryptographic integrity and authenticity of communication relations and confidentiality of configuration data, and Security Class 3 adds confidentiality of all services, including cyclic I/O data. Whether your plant has any of this depends on device and controller support and on configuration.

What are PROFINET Security Classes?

PI's three levels of built-in protection: robustness (Class 1), integrity and authenticity (Class 2) and confidentiality (Class 3). See the table above for what each adds.

What is a GSDML file?

It is an XML file that describes a PROFINET device type: its modules and submodules, communication options, diagnostics and identification numbers. Engineering tools import it to configure devices. A GSDX file is a GSDML file signed by the manufacturer and packaged in an Open Packaging Convention container, so the tool can check that it is authentic and unchanged.

How do I monitor PROFINET without disturbing the machine?

Use a mirror port or a passive TAP, give the capture interface no IP address, capture EtherType 0x8892, LLDP and UDP 34964, and analyse the files offline with Wireshark, tshark or CISA's Zeek parser for PROFINET IO. Never run active discovery on a production cell.

How does PROFINET relate to IEC 62443?

A PROFINET cell maps to a 62443 zone and its uplinks to conduits. PI says its security work aligns with IEC 62443-4-2 for components, and its white paper "OT Security: Classification of IEC 62443" maps the PROFINET security concept onto the 62443 parts.

Where Safeguard fits

Safeguard does not monitor PROFINET networks, configure switches, segment cells, scan device firmware or manage OT assets, and it is not an industrial intrusion detection system. The PROFINET protocol, the IO devices and their firmware are outside what it analyses.

The fit is indirect, but real, in the software your team builds around the plant floor. Edge gateways that collect PROFINET data and push it to a historian, OPC UA bridges, data pipelines in Python or Node.js, container images for an on-site analytics server and internal engineering tools are all ordinary software with open source dependencies. Safeguard can scan those repositories, container images and SBOM files with safeguard scan --dir ., --image <name> or --sbom <file>, match their components against vulnerability databases, show which projects contain a given component and version, rank findings with reachability analysis, and evaluate policies and gates in the platform. That is the same discipline our post on SBOM requirements for industrial control systems argues for at the supplier level.

A rebuilt edge gateway or analytics server pulls its open source libraries again from package registries and base images, and the plant software that reads PROFINET data ships open source components of its own. Those dependencies need the same patch hygiene as any other software you build, even when the controllers and IO devices themselves are patched only by their manufacturers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not PROFINET monitoring or plant network security. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the repository or container image of an edge gateway your team builds to collect PROFINET data, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know what to rebuild after a library advisory.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a vulnerable dependency in a Node.js or Python service that forwards plant data to a historian or dashboard.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• PROFIBUS and PROFINET International: PROFINET overview
• PI: Security activities overview
• PI: PROFINET specification downloads (IEC part mapping, V2.4 and V2.5 notes)
• PI: PROFINET Security Guideline and Security Class 1 Guideline downloads
• PI: White paper OT Security, Classification of IEC 62443
• PI: White paper Contribution of PROFINET to EU CRA Compliance
• PI: Secure Deployment of Industrial Communication Protocols
• PI press release: PROFINET enhanced with further security measures (27 November 2019)
• PI press release: Signed GSDML files for greater security (4 November 2022)
• PI press release: Signing service established for GSD files (14 April 2023)
• PI press release: PROFINET Security Class 1 Plugfest 2024
• PI: GSD files
• PI: GSD signing
• PI: PROFINET RT
• PI: PROFINET IRT
• PI: PROFINET over TSN
• PI: About PI
• PI: Cyber Security Incident Response Team
• PI North America: Security Classes for PROFINET
• BSI Knowledge: IEC 61784-2-3:2023, CPF 3 real-time profiles
• IEEE 802.1: IEC/IEEE 60802 TSN Profile for Industrial Automation
• IEEE 802.1: Time-Sensitive Networking Task Group
• IEEE Registration Authority: EtherType assignments
• Wireshark Wiki: PROFINET
• Wireshark display filter reference: PROFINET DCP
• Wireshark display filter reference: PROFINET RT
• Wireshark display filter reference: PROFINET IO
• Wireshark source: PROFINET DCP dissector
• Wireshark source: PROFINET RT dissector
• CISA ICSNPP: PROFINET IO CM Zeek parser
• CISA: Industrial Control Systems
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
• ISA: ISA/IEC 62443 series of standards
• ODVA: EtherNet/IP
• EtherCAT Technology Group: technology introduction
• Modbus Organization FAQ

Last reviewed: 24 October 2026. The PROFINET specification, IEC 61158 and 61784 editions, ISA/IEC 62443 parts and NIST SP 800-82 are all under active revision; check the pages above for the current editions before relying on a specific part number or security class claim.