Key takeaways
- All three findings trace to the same place: how a device's DCP implementation handles malformed or high-volume protocol traffic, not a credential anyone could have stolen or guessed.
- Security Class 2 (Integrity and Authenticity) — a cryptographically secured digital identity (e.g., certificates) for PROFINET nodes, plus cryptographic checksums so tampering with messages in transit can be detected.
- Treat every PROFINET network as if DCP has zero authentication, because by design it does not.
PROFINET is the Ethernet-based industrial communication protocol PI (PROFIBUS & PROFINET International) maintains for real-time factory-floor control, and the Discovery and Configuration Protocol (DCP) it uses to find and configure devices on the network has no built-in authentication — a gap documented not just in the specification's design but in a decade-long string of CISA advisories against the Siemens products that speak it. PI has answered that gap with three hierarchical Security Classes since 2019, but the CISA record shows most real PROFINET failures so far sit below that layer, in how devices parse and respond to DCP traffic in the first place.
A sourcing note: PI's Security Class 1 Guideline and the "Security Extensions for PROFINET" white paper are distributed as downloadable PDFs that this guide's fetch tooling could not render as extractable text; the Security Class descriptions below are drawn from PI's own HTML security page and its 27 November 2019 press release (both fetched directly), cross-checked against each other. CISA's three advisories are fetched directly from cisa.gov. Confirm exact clause wording against PI's own guideline PDF before citing this guide as authoritative on any single requirement.
Why DCP has no authentication, by design
PROFINET was built for deterministic, low-latency communication between controllers and field devices on the plant floor — a goal that, like Modbus and DNP3 before it, left authentication out of the original design entirely. The Discovery and Configuration Protocol, the piece of PROFINET that lets an engineering workstation find devices on the network and assign them names and IP addresses, runs at Ethernet Layer 2 with no credential check: any station that can send DCP frames can discover, and in some configurations reconfigure, devices on the segment. PI's own security page acknowledges this is a longstanding, known gap — its PROFINET Security Guideline has existed since November 2013, and PI states the guideline is being superseded by one that "considers the PROFINET security concept as well as the requirements of the IEC 62443," rather than a one-time fix layered onto the original protocol.
What that gap actually costs: three documented CISA findings
| Advisory | CVE | CVSS v3 | Weakness | What happens |
|---|---|---|---|---|
| ICSA-21-194-03 | CVE-2020-28400 | 7.5 | CWE-770, Allocation of Resources Without Limits or Throttling | Unauthenticated remote attacker floods a device with DCP reset packets, causing denial-of-service across 70+ Siemens PROFINET product lines |
| ICSA-19-283-02 | CVE-2019-10936 | 7.5 | CWE-400, Uncontrolled Resource Consumption | Specially crafted UDP packet flood triggers the same denial-of-service effect across 60+ further Siemens models |
| ICSA-18-079-02 | CVE-2018-4843 | 5.3 | CWE-20, Improper Input Validation | A single crafted DCP packet from an adjacent network segment forces a device into denial-of-service requiring manual restart |
All three findings trace to the same place: how a device's DCP implementation handles malformed or high-volume protocol traffic, not a credential anyone could have stolen or guessed. That is a structurally different problem than "no authentication" — it means even a device running PI's most advanced Security Class is not automatically protected against a resource-exhaustion bug in its own DCP parsing code; only a vendor patch closes that specific hole. The recurrence across more than 130 combined Siemens product variants, spanning 2018 to 2021, shows this is a protocol-implementation pattern rather than an isolated defect in one model.
PI's three Security Classes: what each actually adds
Per PI's 27 November 2019 announcement, drawing on a white paper titled "Security Extensions for PROFINET" that applies concepts from IEC 62443:
Security Class 1 (Robustness)— access control hardening for SNMP network management, a read-only mode for DCP so devices can be discovered without being reconfigurable over the network, and mandatory cryptographic signing of GSD (device description) files so a tampered device-description file can be detected. PI is explicit that Class 1 adds no cryptographic protection to PROFINET communication itself — it narrows what an attacker already on the network can do with DCP and GSD, it does not authenticate who is sending traffic. Security Class 2 (Integrity and Authenticity)— a cryptographically secured digital identity (e.g., certificates) for PROFINET nodes, plus cryptographic checksums so tampering with messages in transit can be detected. PI states that once both endpoints of a PROFINET Application Relation support at least Class 2, that connection becomes a "secure AR." Security Class 3 (Confidentiality)— adds encryption on top of Class 2's integrity and authenticity guarantees, for the smaller set of applications where confidentiality of the data itself, not just its integrity, matters.
PI also participates in a cross-standard Joint Working Group with ODVA, the OPC Foundation and FieldComm Group — organizations that maintain EtherNet/IP, OPC UA and HART/FOUNDATION Fieldbus respectively — to harmonize device and tooling security approaches across Ethernet-based industrial protocols, under what PI's security page describes as an Industrial Security Harmonization Group. This guide could not independently confirm how far that harmonization work has progressed toward a shared specification; treat it as a direction, not a finished deliverable.
A workable starting point
Treat every PROFINET network as if DCP has zero authentication, because by design it does notSecurity Class 1's read-only DCP mode narrows exposure; it does not add a credential check where none exists in the base protocol. Patch to the versions named in CISA's advisories firstThe three CVEs above are implementation bugs in DCP and UDP packet handling — no Security Class configuration substitutes for the vendor-fixed firmware version that actually closes them. Segment before anything elseKeep PROFINET traffic inside the control network, behind an industrial DMZ, with no path from business IT or the internet — see the Purdue Model for OT/ICS network architecture for the segmentation pattern this implements. Restrict and rate-limit DCP specificallyWhere a managed switch or protocol-aware gateway can filter at this level, limit DCP traffic to the engineering workstations that genuinely need discovery and configuration access, and block inbound DCP from any untrusted segment, matching Siemens' own advisory guidance. Check Security Class support per device, not per vendor claimIf a device genuinely implements Class 2 or 3, prefer it for new deployments; for the large installed base that doesn't, the network-layer controls above remain the real security model, not an interim measure.
PROFINET's DCP weakness is not a bug any one Security Class configuration can retroactively fix in deployed hardware; it is why NIST SP 800-82's OT security guidance and IEC 62443-3-3's system security requirements both treat network-level compensating controls as the baseline for legacy field protocols, PROFINET included, alongside Modbus, DNP3 and BACnet. SoftWSP's OT Snapshot builds a passive, factual picture of which devices on a shop floor are actually speaking PROFINET, and to whom, from a mirror port, without touching production traffic: see OT Snapshot.
This guide draws on PI's own security page and press release (fetched directly) and CISA's three published ICS advisories (fetched directly), cross-checked against each other where PI's underlying guideline PDFs could not be rendered as extractable text. This guide is not a substitute for PI's own PROFINET Security Guideline, CISA's or Siemens' own advisories, or an engineer's assessment of a specific network.
Sources
- PI (PROFIBUS & PROFINET International): PI Security — PROFINET Security Guideline, Security Classes, IEC 62443 alignment, Joint Working Group
- PI: Press release — "PROFINET enhanced with further security measures" (27 November 2019): Security Classes 1/2/3 and the "Security Extensions for PROFINET" white paper
- CISA ICS Advisory ICSA-21-194-03: Siemens PROFINET Devices (Update D) — CVE-2020-28400
- CISA ICS Advisory ICSA-19-283-02: Siemens PROFINET Devices (Update L) — CVE-2019-10936
- CISA ICS Advisory ICSA-18-079-02: Siemens SIMATIC, SINUMERIK, and PROFINET IO (Update D) — CVE-2018-4843
- NIST Special Publication 800-82 Revision 3, Guide to Operational Technology (OT) Security (September 2023)
- CISA: Recommended Practices (control systems network segmentation, defense-in-depth, minimizing network exposure)
Frequently asked questions
Does PROFINET have built-in authentication or encryption?
Not by default. PROFINET — the Ethernet-based industrial communication protocol maintained by PI (PROFIBUS & PROFINET International) — was designed for real-time determinism on the factory floor, and its base specification, including the Discovery and Configuration Protocol (DCP) used to find and configure devices on the network, carries no field for a credential, a session key or a signature. Per PI's own security page, this gap is why PI has published security guidance since 2013: the original PROFINET Security Guideline (Order Nos. 7.001, 7.002, first published November 2013) covers manufacturer- and user-side technical and procedural measures, and PI states that guideline "will be replaced by an updated guideline that considers the PROFINET security concept as well as the requirements of the IEC 62443" — confirming the base protocol itself was not designed to secure itself.
What are PROFINET's three Security Classes?
Per PI's 27 November 2019 announcement, PI defined three hierarchical Security Classes for PROFINET components, drawing on IEC 62443 in a white paper titled "Security Extensions for PROFINET." Security Class 1 (Robustness) introduces improved access control for network management (SNMP), a read-only mode for device discovery and configuration (DCP), and mandatory cryptographic signing of GSD device description files — but per PI's own description, it adds no cryptographic protection to PROFINET communication itself. Security Class 2 (Integrity and Authenticity) adds a cryptographically secured digital identity for PROFINET nodes (e.g., certificates) and cryptographic checksums so the authenticity and integrity of communication can be verified. Security Class 3 adds confidentiality on top of Class 2's integrity and authenticity. PI states that PROFINET Application Relations can become "secure ARs" once both endpoints support at least Security Class 2.
What do real, documented PROFINET security failures actually look like?
CISA's ICS advisory archive shows a recurring pattern specific to the Discovery and Configuration Protocol: CVE-2020-28400 (CISA ICSA-21-194-03, CVSS v3 7.5, CWE-770 Allocation of Resources Without Limits or Throttling) lets an unauthenticated remote attacker send a large volume of DCP reset packets to trigger denial-of-service across more than 70 Siemens PROFINET-speaking product lines. CVE-2019-10936 (CISA ICSA-19-283-02, CVSS v3 7.5, CWE-400 Uncontrolled Resource Consumption) lets an attacker flood a device with specially crafted UDP packets for the same effect, across more than 60 further Siemens models. CVE-2018-4843 (CISA ICSA-18-079-02, CVSS v3 5.3, CWE-20 Improper Input Validation) shows the same class of weakness exploitable from an adjacent network segment: a single crafted DCP packet forces a manual restart. All three sit in how devices parse and respond to DCP traffic, not in any one product's otherwise-unrelated code.
Is Security Class support actually deployed, and does it stop the DCP advisories above?
This guide could not independently confirm how broadly Security Class 1, 2 or 3 support is implemented across the installed base of PROFINET devices — treat a vendor's claim of Security Class support as something to verify against that specific product's own documentation and firmware version, the same caveat that applies to Modbus Security and DNP3 Secure Authentication adoption. What is clear from the CISA advisories themselves: the DCP denial-of-service findings above are implementation-layer parsing and resource-handling bugs, not failures of cryptographic authentication — so even a device that fully implements Security Class 1's read-only DCP mode or Class 2's node authentication still needs the vendor's own patched firmware to close these specific CVEs; Security Classes compensate for a different gap (identity and integrity) than a resource-exhaustion bug in DCP packet handling.
What actually reduces PROFINET risk today?
The same compensating-control model NIST SP 800-82 Revision 3 and CISA's recommended practices apply to every unauthenticated legacy OT protocol: segment PROFINET traffic behind an industrial DMZ so it is never reachable from business IT or the internet, patch to the vendor-fixed firmware versions named in each CISA advisory, and where a switch or gateway can filter protocol traffic, block or rate-limit DCP and restrict it to the engineering workstations that actually need it. Siemens' own advisories additionally recommend blocking inbound PROFINET Discovery and Configuration Protocol traffic from untrusted sources and disabling PROFINET device discovery where it isn't operationally required.
In this cluster
