Every device that connects to your plant network gets a decision made about it. Something determined that this identity is allowed to be here and what it is allowed to reach. The problem in most plants isn’t that the decision was wrong. It’s that it was made once, by hand, at install, by someone solving an immediate problem — and nothing has revisited it since. That’s the gap between a device inventory and access control, and it survives all four of the approaches teams actually use. You almost certainly have at least one.
1. The Spreadsheet
It exists. Someone built it, probably during an audit or an insurance renewal, and it was accurate on the day it was written. It has MAC addresses, a location column, maybe an owner column that’s half-populated.
For a small IT team covering multiple plants, building this was proportionate, not negligent. The issue is structural: a spreadsheet records a past state and isn’t wired to anything that can act on the present one. When a contractor laptop appears on a plant segment at 2am, it does not know, cannot know, and could do nothing if it did.
2. Monitoring That Alerts but Can’t Act
This is the most valuable of the four, and the most commonly mistaken for the thing it isn’t. Passive Operational Technology (OT) monitoring fingerprints devices without touching them, which matters where active scanning can knock over a Programmable Logic Controller (PLC). It builds a continuously updated picture and catches anomalies nothing else would see. If you have it, you made a good decision.
But detection is not admission control, and the distinction is operational. Detection means someone gets an alert. Perhaps at 2am, on third shift, as one of four hundred that day. They have to decide whether it matters, which requires knowing what normal looks like on that line. Then they have to act, which means finding a switch port, finding someone with access to that switch, and making a phone call. By the time that chain completes, the device has been on the network for hours.
3. Authentication That Doesn’t Profile
Remote Authentication Dial-In User Service (RADIUS) is the protocol that checks a credential when something asks to join the network. Microsoft’s Network Policy Server (NPS) is the incumbent here — not because anyone evaluated it against alternatives, but because it ships with Windows Server and someone stood it up years ago for wireless.
NPS answers one question well: does this credential check out? That’s authentication, and it’s necessary. But the plant floor needs a different question answered: what is this thing, and should it be here?
Those come apart constantly. A valid domain credential on an unmanaged contractor laptop authenticates. So does a shared integrator service account, and so does a device with a certificate issued in 2019 for a machine an OEM depot has since re-imaged. The credential is real and the device is not what the network thinks.
Credentials tell you what a device claims to be. Profiling tells you what it actually does — the traffic it generates, the protocols it speaks, the pattern it settles into. NPS only ever sees the claim.
4. Network Access Control Parked in Monitor Mode
This is the one nobody talks about, and it’s extremely common. Network Access Control (NAC) was purchased, sometimes years ago. It was deployed. It is logging faithfully. But it is enforcing nothing.
The reason is almost never technical, but the failure would be. Flip enforcement on a Tuesday afternoon, between shifts, and twenty minutes later the HMI on line 3 could drop — not because of an attacker, but because its certificate was issued at commissioning, expired eighteen months ago, and nothing was watching for that until enforcement started checking. Now it’s you explaining to the plant manager why the line is down, and the answer is: you did it, on purpose, with a change you approved. So the sensible move, the one any competent engineer makes, is to run monitor mode first and study the logs.
Then the confidence never arrives. The engineer who understood the deployment moves on. Flipping enforcement on becomes a project requiring someone to own the risk, and the person who could have owned it has left. The deployment still counts, though. It appears in the security stack, in the questionnaire, and on the renewal application.
Why All Four Feel Like Enough
Each of these was a defensible decision under real constraints. The spreadsheet proportionate, the monitoring OT-safe, NPS already there, monitor mode engineering caution. None is negligence. That’s the first reason nothing changes.
There’s a second reason, and it’s subtler. Every one of the four says the right thing. The spreadsheet says you have an inventory, and it satisfies the auditor. The dashboard says you’re watching. NPS says you authenticate. The NAC deployment says you control access. Each is real evidence that you take the problem seriously, which is exactly why nobody asks what any of them does about a device that shouldn’t be there. Monitor mode is the sharpest and costliest: you pay for enforcement capability while operating with none.
There’s a third reason nothing changes. Fixing any of this means touching the network, and a plant running three shifts has no window in which to touch it. The work waits for the annual shutdown, the shutdown gets compressed by a customer commitment, and the security item is the first thing cut because it isn’t producing parts.
What Makes a Device Controlled Rather Than Seen
Each failure points at something control actually requires.
The spreadsheet fails because a record can’t act. Control has to be enforceable, connected to something that can permit or deny rather than describe.
Monitoring fails because a human sits in the loop. The decision has to happen at admission, before the device is on the network, not after someone reads an alert on third shift.
Authentication without profiling fails because it trusts a claim. The decision has to rest on what the device does, established independently, rather than on what it says about itself.
Monitor mode fails because the decision was never applied. The policy has to actually run.
And the thread through all four: the decision cannot be static. It has to be re-made, repeatedly. A device that was safe at install can stop being safe without changing its address, its credential, or anything else your tooling records. The contractor’s engagement ends. The machine comes back from depot with different firmware. A potential attacker removes anti-virus from a laptop. Nothing notices, because none of these methods were built to notice.
Find Your Access Gaps
Identify which of these four methods you use, and be honest about the fourth, since monitor mode is easy to miss. Then run one test: connect a device type that shouldn’t be on a production segment, in a controlled window, and time how long until something either stops it or tells a human. Not how long until it appears in a log. How long until a decision gets made. That interval is your real access control posture.
Inventory Doesn’t Answer the Access Control Question
An inventory gives you visibility. It tells you what is present. Control determines what is permitted, and keeps determining it.
The four methods above share one property: a decision made once and never revisited. Portnox revisits it constantly. Each device is judged on what it does rather than what it claims, at admission rather than after an alert, and judged again the moment its posture changes.
None of that requires an appliance in your plant, or a maintenance window to install one. Which matters, because the reason this gap persists probably isn’t that you disagree with any of it. It’s that fixing it has never been schedulable.
Learn More about Portnox Cloud