PLC-to-phone alerts and the Purdue Model: when is it OK to skip the SCADA?

From Prompt to Plant is the series where we share, openly and in full, the prompts that let you program an Industrial Shields PLC with Claude Code. This article answers the best question episode 1 received.

The question

In episode 1, we programmed an ESP32 PLC 14 to send pump-failure alerts straight to a phone via Telegram — no SCADA, no middle server. A reader asked the question every controls engineer should ask:

"How does this interfere with the Purdue Model for ICS security?"

It is a fair question, and the honest answer is worth an article.

What the Purdue Model says

The Purdue Model is the classic reference architecture for industrial networks. It organises a plant into levels — sensors (0), controllers/PLCs (1), supervision/SCADA (2), plant operations (3), a DMZ (3.5) and enterprise IT/internet (4-5) — and mandates that traffic climbs one level at a time, through controlled boundaries. A PLC talking directly to an internet API jumps from level 1 to level 5. Under a strict reading, that is exactly what the model exists to prevent.

Security is proportional to what you are protecting

Here is the part that often gets lost: the Purdue Model describes plants that have an OT architecture. A huge share of real-world installations do not. A pumping station in a field. A workshop with three machines. An isolated packaging line. No SCADA, no segmented network, no DMZ — and no alerts of any kind. Whoever runs that machine is not thinking about reference architectures when it stops at 3AM: they just want to know. Finding out three hours late has a very real cost.

For those installations, the realistic alternative to "PLC sends a Telegram message" is not a hardened Purdue stack. It is nobody finding out for hours. Risk-based security means comparing the pattern against the actual alternative, not against a reference architecture the site never had.

Even then, the episode 1 pattern is deliberately conservative:

• Outbound-only. The PLC opens a TLS connection out to port 443. No inbound port is opened; the PLC is not reachable from the internet.
• Notify-only. It sends state changes; it does not poll for or accept incoming commands.
• Egress can be pinned. At the router or firewall, allow outbound traffic to api.telegram.org only, and nothing else.
• Inputs-only hardware. If the PLC has only inputs wired (pure monitoring, no outputs), the worst case of a compromise is a false or missed alert — never an action on the machine.
• Own network segment. Put the monitoring PLC on its own VLAN or a 4G SIM: it neither sees nor touches any other level.

Two lines that matter. First: alerting is not functional safety — the machine protection remains the hardwired thermal relay; the Telegram message is a best-effort notification on top, never a safety layer. Second, precision matters when defending the pattern: the firmware not accepting commands is a design decision verified in code review (it never polls for updates), not an architectural impossibility — an established outbound connection can carry data back if the code asks for it. That review gate is part of the security.

If your plant HAS an OT architecture: do not jump levels

In a segmented plant, the direct pattern is the wrong one — and the right one is already in episode 1 as the "variant": the PLC publishes its events over MQTT to a broker in the DMZ (or level 2/3), and a service in that zone — Node-RED, for example — is the only thing that talks to the internet. The PLC never leaves its zone; the notifier is a controlled conduit you can audit, patch and revoke in one place.

The programming surface

The thread behind this article raised a second sharp question: how is the PLC programmed — and is that a door? The first time is over USB. After that, you can enable OTA updates over the network so nobody has to walk to the cabinet — and that surface is decided at compile time: if you do not include OTA support in the firmware, that path simply does not exist; there is no service listening to protect. If you do enable it, it ships with a password, signed firmware and access only from the maintenance VLAN. In short: the firmware is the gate. "Exposed" is not a property of the device — it is a property of what you compile into it, and that is exactly what the engineering review verifies.

IEC 62443, in three ideas

The modern, certifiable standard for ICS security is IEC 62443. If Purdue is the classic drawing, 62443 is the current rulebook. Three ideas cover most conversations:

1. Zones and conduits. Group assets into zones by criticality; define the controlled conduits through which zones may talk. The DMZ pattern above is exactly this.
2. Security Levels (SL1-SL4). Each zone gets the protection its threat model requires — from accidental misuse (SL1) to a skilled adversary (SL4). Not everything needs SL4; deciding consciously is the point.
3. Roles. The standard splits duties between product supplier, integrator and asset owner. Everyone owns a piece.

The honest checklist

• Isolated asset, no OT network, no alerts today → direct outbound-only pattern is a pragmatic win. Pin the egress, keep it notify-only and inputs-only where possible, validate on the bench.
• Segmented plant with SCADA/DMZ → PLC publishes MQTT inside its zone; a DMZ service sends the notification. Never level 1 → internet.
• Hardening for production → validate the TLS certificate (pin the CA instead of skipping verification), treat the bot token as a credential (rotate it, never commit it to a repository), and have a firmware update plan.
• Either case → the AI writes the code, the engineer reviews it, and the same review gate applies whether the code was written by a human or a model.

Every week, one real, verified prompt. This article was born from a reader's question — keep them coming. Full archive and upcoming episodes on this blog, and in the From Prompt to Plant newsletter.