Presented by
Happy October 20th, Industry 4.0!
Halloween is twelve days away, which means every plant is running its annual ritual: somebody tapes a paper skeleton to the safety board, and everyone pretends it isn't there until November.
The scary stuff this week is quieter. A patch you've been meaning to schedule. A permissions setting nobody has looked at since commissioning. A system with an expiration date that's still more than a year out, right up until it isn't. None of it makes the evening news, but all of it decides how your next shutdown goes.
This week is about managing change. Siemens and Rockwell have a patch list for you. Ignition has a role-check worth doing before lunch. Anthropic outgrew git (yes, really), and there's a lesson in it for anyone with a folder named "PLC_backup_FINAL_v7_REAL." And SAP's customers have some opinions about their own calendar.
Grab your coffee. Here's what caught our attention:
Siemens and Rockwell Patch Day: What to Put on Your Maintenance Calendar
Siemens published 17 new advisories on Patch Tuesday, and Rockwell disclosed a critical flaw that can hand over an I/O block's admin account without a login.
The details:
- Siemens: Critical-rated advisories cover some Simatic S7-1500 CPUs, Industrial Edge devices, and the Ruggedcom Crossbow Station Access Controller. The CPU item involves more than 400 flaws in the GNU/Linux subsystem inside some Simatic CPUs
- Also from Siemens: High-rated advisories for Simatic IPC, WinCC, Industrial Edge App Publisher, Desigo, and others. Some issues have patches. Others have interim mitigations until permanent fixes ship
- Rockwell: Advisory SD1801 covers two flaws in the 1732E ArmorBlock. The critical one lets an unauthenticated attacker change the device's web server password, which can lead to admin account takeover. The second is a denial-of-service issue
- ABB: A credential-reset bypass in dynovaPRO (CVE-2026-18963) could allow account takeover. ABB knows of no in-the-wild exploitation, but its logs showed 26 password-change events across 9 customers that it says may indicate testing or reconnaissance
- Schneider Electric: Two high-severity advisories, covering Pro-face STW6000/Harmony STW6 devices and Sage RTUs
Why it matters: Here's the thing about OT patching: it's not Patch Tuesday for you, it's "Patch whenever the line is down." That's exactly why the distinction between patched and mitigated matters. A fix you can't apply until the March shutdown is a mitigation problem today.
None of this is a reason to lock the plant down and stop building. It's a reason to know what you own.
Real-world scenario: Line 3 has a handful of ArmorBlock I/O modules bolted to the conveyor frame. Nobody has logged into their web pages since the day they were installed, which is the whole problem. The password hasn't been touched in years, and the web server is reachable from the same VLAN as half the office laptops. Imagine your controls engineer asking: "Can anyone who can ping this thing reset the admin password?" On unpatched 1732E firmware, the answer is yes.
What to do this week:
- Pull your asset list by vendor and model, then match it against the Siemens, Rockwell, ABB, and Schneider advisories
- Sort every hit into three buckets: patch now, mitigate until the next window, not affected
- Check where your ArmorBlock web servers are reachable from. If it's anywhere beyond engineering, fix the network path first
- Get the next outage window on the calendar with firmware staged ahead of time
The bottom line: Patch Tuesday is a list. Your maintenance calendar is the plan. Make sure one actually feeds the other.
Ignition Gateway Flaw: A Vision Login Can Become Designer Access
CISA published an advisory on October 13 for a privilege-escalation flaw in Inductive Automation's Ignition (CVE-2026-92817), and the fix is a version bump you can plan today.
The details:
- The flaw: Ignition's Perspective module doesn't properly validate session privileges when granting Designer-level access. A user with access to a Vision project can use their valid Vision session ID to gain Designer privileges, which could mean arbitrary code execution in the Gateway process
- Severity: CVSS 8.8 (v3.1) and 8.7 (v4.0)
- Affected: Ignition 8.1.0 through 8.1.54, and 8.3.0 through 8.3.8
- Fixed in: 8.1.55 and 8.3.9
- Exploitation: CISA reports no known public exploitation targeting this flaw
- Credit: Researcher Tim Hemingway
Why it matters: Translation: this isn't an "anyone on the internet" bug. The attacker needs a valid login with access to a Vision project. But think about how many of those exist in your plant: operator accounts, shared logins, contractor accounts, the one the integrator set up in 2019 and never removed. A low-privilege account that can become a Designer account is a permissions model problem, not just a software bug.
Ignition is everywhere in our community, so this one likely applies to somebody reading this.
Real-world scenario: Your Gateway runs the packaging line's Vision clients. An operator account that was only ever supposed to view dashboards can, with this flaw, end up with Designer-level rights, and Designer-level rights on a Gateway can mean running code on the box that talks to your PLCs. Imagine your maintenance supervisor asking: "Who actually has a Vision login, and do they all still work here?"
What to do this week:
- Check the version on every Gateway you run: 8.1.54 or earlier, or 8.3.8 or earlier, is affected
- Plan the upgrade to 8.1.55 or 8.3.9 or later, with a Gateway backup first
- Until then, remove Vision project access from accounts that don't need it
- Confirm the Gateway isn't exposed to the internet, and that remote access goes through a VPN
- Review recent Designer launches and Gateway process activity for anything you can't explain
One caveat worth knowing: CISA's description (privilege escalation) and the vendor's (remote code execution) don't match word for word, and the fixed-version release dates in the advisory look like typos. Confirm versions and dates in Inductive Automation's Trust Center before you build a change ticket around them.
The bottom line: The patch is easy. The harder question, who has access to what, is the one worth answering anyway.
Read the CISA advisory (ICSA-26-286-01) →
Anthropic Outgrew Git. Here's What It Means for Anyone Who Has Ever Emailed a PLC Program.
Anthropic replaced git with an in-house version control system called Scion, and the reason is a story about what happens when AI writes code faster than people can review it. (Disclosure: this is Anthropic's own write-up of its own system, so the numbers below are the company's.)
The details:
- The scale: Merges to Anthropic's main monorepo grew from about 2,500 a day in May to more than 30,000 a day by September, driven by AI-generated code
- The pain: CI was doing roughly 25 million checkouts a day. Fetched naively, Anthropic says that would be over 600 petabytes of git traffic daily
- The insight: Git was designed to work offline. Nearly all of Anthropic's clients were always-online agents and jobs, so that design was working against them
- The result: A centralized, horizontally scalable system with server-side commits and sparse working copies. Anthropic reports about 200x lower CPU and memory than its prior setup, and CI checkouts in seconds instead of minutes
- The team: Seven engineers built Scion and a companion code review tool, and finished the migration in five months
Why it matters: You're not running 30,000 merges a day, and Anthropic says plainly that Scion isn't a git replacement for most organizations. So why is this in a manufacturing newsletter?
Because of what the engineers said changed. Their main contribution shifted to design judgment and constraining AI-generated code that violated system principles. They review the intent of a change instead of every line. The bottleneck moved from writing to reviewing and proving.
Controls work is heading the same direction. PLC logic, HMI screens, Ignition projects, gateway configs, and UNS topic schemas are all code, and AI assistants are writing more of it every month. Our Discord spent the week arguing about exactly this (see "From the Floor").
Real-world scenario: An integrator uses an AI assistant to generate tag-mapping scripts for 40 machines in an afternoon. Great. Now someone has to confirm that machine 27's mapping didn't quietly swap a setpoint with a limit. Imagine your plant manager asking: "Who approved this, what did it change, and can we roll it back before second shift?" If the answer is "a file on someone's laptop," you have a version control problem, whether or not AI is involved.
What to do this week:
- Put the things that run your plant under version control: PLC project exports, HMI/SCADA projects, Gateway backups, UNS schemas. Plain git is more than enough at your scale
- Decide what must get a human review (anything touching safety, interlocks, or setpoints) and what automated checks can cover (naming conventions, tag mappings, simulation runs)
- Require test evidence with any AI-assisted change: a simulation log or FAT result, not "it looked right"
- Require a short change note stating the intent, so reviewers can check the change against what it was supposed to do
The bottom line: Scion solves a problem you don't have. The discipline behind it, knowing what changed and why, is one you do.
Sponsor Message
Keep your history. Keep your Postgres.
Every PLC tag, sensor, and machine state on your floor writes a new reading every few seconds. Multiply that by a year of history and every IIoT team lands on the same two questions: where does all of it live, and who has to maintain it?
Tiger Data keeps the answer simple with Tiger Cloud: it's their fully managed PostgreSQL solution, built for time-series, so your team keeps the SQL it already knows.
- Built for time-series data: Tables partition by time automatically, and older data converts from fast row storage to columnar. Compression can reach up to 95%, with automatic tiering to low-cost object storage for long retention
- Built to stay up: Multi-AZ clusters with automatic failover, point-in-time recovery, and cross-region backups
- Built for your security review: SOC 2, HIPAA, and GDPR compliance, always-on encryption, SSO, role-based access control, and audit logging
- Built for scale: Tiger Data has proven that a single Tiger Cloud service can handle 3 trillion metrics a day and 3 petabytes of data
Try it on your own data: New Tiger Cloud accounts get $1,000 in credit, valid for 30 days, with no credit card required. New accounts only.
Create an account and get $1,000 in credit →
SAP Users to SAP: Let Us Set Our Own Timeline
At the DSAG congress, the German-speaking SAP user group told SAP, in plain terms, that customers want to choose their own pace, deployment model, and AI terms, with the ECC clock ticking down.
The details:
- The audience: More than 6,000 people at DSAG's 27th annual congress
- The deadline: Per DSAG's early-2026 survey, 54% of companies still run SAP ECC or Business Suite, and standard maintenance for ECC ends at the end of 2027
- The AI gap: 43% of respondents had implemented AI use cases as of January, mostly with non-SAP solutions
- The asks: Accept that on-prem and hybrid S/4HANA are everyday reality, not exceptions. Don't tie AI features to cloud contracts. Offer fair, transparent licensing. DSAG called SAP's plan to offer selected AI scenarios to on-prem customers through RISE only a first step
- The warning: DSAG's outgoing CEO said the gap between vision, available technology, and practical application is widening
Why it matters: A quick disclosure: the article covers SAP customers broadly, not manufacturers specifically, and DSAG represents German-speaking users. The takeaways for plants below are our read, not DSAG's.
Here's the thing about an ERP migration: the ERP team calls it a project, but the plant calls it "what happens to my production confirmations." Your MES, your maintenance system, your quality workflows, and your warehouse scanners often talk to ERP through interfaces someone built years ago. When ERP changes, those connections are what break.
Real-world scenario: Your MES posts production confirmations and material movements to ERP overnight. It's been stable for a decade, so nobody remembers how it works. Imagine your plant manager asking in a budget meeting: "If corporate moves ERP in 2027, what stops working on the floor, and who pays to fix it?" If the answer starts with "we'd have to look into that," you have a long list to build.
What to do this week:
- Inventory every plant-to-ERP touchpoint: production confirmations, material movements, quality notifications, maintenance orders
- Ask your MES and integration vendors, in writing, what their S/4HANA support roadmap is and what it will cost
- If you run on-prem, get deployment options and AI access terms priced side by side before the renewal conversation, not during it
- Keep your plant data in a layer you control, like a UNS or historian, so a future ERP swap doesn't mean re-plumbing everything
The bottom line: Your ERP's calendar isn't yours to set, but what your plant depends on is. Find the dependencies before the deadline finds them for you.
From the Floor: A Week in the Community
From October 12 to October 18, the 4.0 Solutions / Industry 4.0 Discord kept circling one question: what does AI do to the work of building software, and what does it cost? The week ended with a sharp UNS governance question that no one has answered yet, so consider this your invitation.
AI, token costs, and the 400-page problem: Members worked through what AI changes about software work: "prototype as spec," hyper-specific software, token costs as a real line item in a build, and small teams outrunning big ones (someone shared ghuntley.com/replaced/). One question from #💬-general is still open: how do you apply TDD to a larger team? Then sparkylarks and .killnine both hit the same wall from different directions: AI-generated 400-page user requirement specs. The model writes too much, and humans won't read it. donpancoe offered a sharp follow-up: if the value of code is dropping and the value of data is rising, build-versus-buy becomes a data-ownership question. (Sound familiar? See Anthropic, above.)
What an Ignition deployment actually costs: A detailed community back-of-the-envelope for an Ohio deployment, roughly 15 PLC connections and 40 dashboards, came out at about 250 to 400 person-hours at a $150-an-hour regional rate, courtesy of sparkylarks. If you're scoping a project, it's worth a read as a sanity check for your own estimate.
The UNS control plane question (still open): In #unified-namespace on October 18, tomashidalgo0847 argued that most UNS conversation is about the data plane (MQTT, Sparkplug, ISA-95) and skips governance: schema registries, versioning, ownership, and how changes propagate safely. No replies yet. It's the same theme running through this whole issue, so if you've got a battle-tested answer, jump in.
Also worth a look: michaelfrostbilling_95019 has been sharing his open-source fss-mqtt-broker and fss-mqtt-browser projects and offering to bounce ideas with anyone interested. vikanchira asked whether NATS.io is a viable high-availability alternative to free MQTT brokers, hasn't gotten answers yet, and started a spike on it himself. And mellamomark wants to know who's playing with local or open-weight AI models. New faces this week came from data science, cryogenics, and CNC machining, so say hi if you see someone new.
Not in the room yet? Come hang out in the Discord → That's where the real work gets argued out.
Byte-Sized Brilliance
Git Was Built in About 10 Days. Then It Ran the World for 20 Years.
Linus Torvalds made the first git commit on April 7, 2005, after Linux kernel developers lost access to BitKeeper, the proprietary tool they'd been using, over a licensing dispute. By his own account it took "about 10 days until I could use it for the kernel." A tool that now sits under much of the world's software was a short sprint to solve an urgent problem.
It was designed around a clear assumption: distributed, with every copy of a repository equal and no central server required. For two decades, that assumption was a feature. Then Anthropic's heaviest users turned out to be AI agents that are always online and merge tens of thousands of changes a day, and the assumption that made git great became the thing Anthropic had to design around.
That's the quiet lesson in this week's issue. Every system you run is a stack of assumptions from the day it was built: your ERP's support window, your Gateway's permissions model, your PLC naming scheme. Most of the time you never see them. Then a workload changes, and the assumption nobody wrote down is the one that breaks.
Every system is a set of assumptions waiting for a workload that disproves them.
Sources: GitHub Blog, "Git turns 20: A Q&A with Linus Torvalds" (April 7, 2025); Anthropic Engineering, "Redesigning source control at Anthropic" (October 13, 2026).
Responses