## A connected factory doesn’t go down because of “a virus”—it goes down because of invisible decisions
When a manufacturing company tells me “we’re afraid of a cyberattack,” I don’t start with threat talk.
I start with what they can feel:
-
- downtime
-
- missed dates
-
- rework
-
- rescheduling
-
- margin leakage.
In a connected factory, the incident rarely arrives with an alarm. It arrives as dangerous normality: an access that shouldn’t exist, inherited permissions, shared passwords, a “temporary” laptop that stays forever, an exception nobody documented.
One day, operations realizes continuity depends on things leadership never explicitly decided.
## What I mean by “connected factory” (and why it changes risk)
A connected factory is not just machines on a network. It’s a workflow where you mix:
-
- planning and management systems
-
- workstations
-
- industrial networks
-
- capture devices (scanners, tablets, sensors)
-
- and data flows crossing boundaries for speed.
Speed is real. The consequence is also real:
if identities and access aren’t governed, the factory becomes fragile.
Not fragile because of tech. Fragile because of missing limits.
## The most common mistake: buying “security” like it’s a box
Too many teams treat cybersecurity as:
-
- an antivirus
-
- a device
-
- a vendor “who handles it”.
Operational cybersecurity is not a thing you buy. It’s a discipline you build.
And it starts with an uncomfortable question:
who can touch what—and what happens if they’re wrong?
If you can’t answer, continuity is built on trust.
## What’s actually at stake: continuity, promise, reputation
In project-driven operations, the chain is sensitive:
-
- factory stops → dates move
-
- dates move → coordination explodes
-
- coordination explodes → decisions degrade
-
- decisions degrade → rework appears
-
- rework eats margin.
That’s why I don’t treat cybersecurity as “IT’s topic.” I treat it as:
-
- operational continuity
-
- real capacity
-
- defensible promises.
One principle rules them all:
what isn’t bounded becomes an incident.
## The OT/IT boundary: where most pain starts
Without jargon: there are two worlds.
-
- the “management” world (users, apps, documents, ERP/CRM)
-
- the “operations” world (machines, control, production).
Connecting them is normal—you want data and visibility.
Risk appears when the connection has no rules and becomes an informal bridge:
-
- uncontrolled cross-access
-
- personal devices where they don’t belong
-
- remote tools without traceability
-
- exceptions that become routine.
My red flag is cultural, not technical:
when the factory runs because “someone knows,” not because the system enforces boundaries.
## “It won’t happen to us” often means “we wouldn’t see it coming”
Impact doesn’t require being a “target.” It requires being exposed.
And the dangerous part: a serious incident doesn’t always look like “cyber.” It can look like:
-
- a weird Monday
-
- logins failing
-
- systems slowing down
-
- orders “disappearing,”
-
- files that won’t open.
If you don’t have operational signals, you call it “an IT problem”… until it’s too late.
## Nine signals that tell me you’re exposed (without touching anything)
1) shared passwords for critical access
2) generic users (“operator”, “admin”) with no individual traceability
3) inherited permissions (“leave it, it works”)
4) remote access without a clear log of who did what
5) devices with no owner
6) backups assumed good, but recovery never tested
7) updates postponed forever because “we can’t stop”
8) duplicated data across systems (multiple truths)
9) repeated minor incidents normalized (“it always happens”)
None of these are “just technical.” They’re governance signals.
## The real core: identity, permissions, traceability
If I had to keep one layer only, it’s this:
identity + permissions + traceability.
Most damage isn’t caused by movie villains. It’s caused by:
-
- access that’s too broad
-
- changes with no trail
-
- decisions you can’t audit.
I ground it with three questions:
1) who is the person (not the role)?
2) what can they do exactly (read/edit/execute/approve)?
3) what evidence remains (can you reconstruct tomorrow without memory)?
When these are clear, you stop operating on assumptions.
## The “full autonomy” myth: you need gates
Real operations need balance:
-
- routine flows
-
- critical actions pass a gate
-
- irreversible actions require approval.
That’s not bureaucracy. It protects margin.
A gate is the line that prevents one wrong action—or one human mistake—from becoming downtime.
## What breaks first in an incident
Usually, coordination breaks first:
-
- the factory doesn’t know what to prioritize
-
- the office doesn’t know what to promise
-
- procurement doesn’t know what to confirm
-
- leadership doesn’t know what to believe.
The event is not the whole problem. The lack of a decision framework under pressure is.
That’s why cybersecurity in a connected factory is also crisis readiness: the ability to decide with evidence.
## Diagnostic questions I use to measure your blast radius
1) if a key system goes down tomorrow, what production can continue?
2) how fast can you identify which orders are at risk?
3) do you have a clear list of “critical” assets and access paths?
4) who can stop production and who can resume it?
5) what remote access exists today, and who audits it?
6) can you restore from backups and prove it with a recent test?
7) do changes leave an approval trail?
8) what happens when two systems disagree on “truth”?
9) does your team know who to call and what to decide first?
If these are fuzzy, it’s not a team failure. It’s a design opportunity.
## Closing
I’m not trying to scare anyone. I’m trying to remove heroics from continuity.
In a connected factory, cybersecurity is part of the promise: dates, quality, responsiveness, continuity.
If you want, I’ll review it with you in 15 minutes: your most likely exposure points (without drama), your real blast radius, and the criteria to decide where to start without freezing the operation.
