There is something you have been getting ready to start for about two years now, but for whatever reason, you haven’t yet.
I know, because two years ago, I had one too. Mine was a 5K run.
5K is not an impressive distance, and although I did not understand it at the time, that turned out to be the entire point. I signed up because signing up was the smallest version of the decision I could make, and because a date on a calendar is harder to argue with than an intention.
I am now in training for my second half marathon. This one is a trail race, and I will climb more than a thousand feet of elevation on the way around it.
That wasn’t the plan. There was no plan. There was only a 5K.
Starting is the hard part.
Two years ago I could not have trained for a thousand-foot climb. Not because I lacked discipline, but because training for that isn't an option until you are moving. You cannot build a base if you have not started. The 5K did not turn me into a runner. It made me a person with a training schedule, and that schedule made the rest possible.
This is the part people (me included) get backward. We treat the start as the reward for being ready. It is the opposite. The start creates readiness, and everything you are waiting to feel before you begin is downstream of the beginning.
Once I started, the obstacles changed: achieving the first 1K and being bad at it; when there was no evidence of improvement; when quitting would have cost me nothing, and nobody (not even my wife) would have noticed.
I built marketing agents and skills the same way (not on purpose)
I wrote last week about adding AI agents to the marketing team at BlastWave, and I want to correct an impression that piece might have left. Read end-to-end, it sounds like a design. Three layers of review, skills that encode how we actually work, materiality thresholds, persistent logs, a human who approves everything before it reaches a customer. It reads like an architecture somebody drew on a whiteboard and then built.
For me it was another 5K.
The whole thing started with one narrow, unglamorous thing: I wanted a single page each week that read our systems and told me what moved. That’s all. I wasn’t building a control architecture. I was just tired of assembling that page by hand and doing it badly.
Everything in the system now works because the first version failed in ways I could only find by running it. The validation gate exists because GA4 was reporting more new users than sessions, which is arithmetically impossible, and had been reporting traffic flat within a few percent for six months, which real traffic does not do. I had trusted that data for a year. The rule that we fix the skill rather than the output exists because a check kept flagging the same non-defect every week until I realized it was applying a generic assumption to a company that doesn't work that way.
I hadn’t thought of any of that in advance, and there’s no way I could have. Finding, identifying, and rectifying these failures required something to be running.
Stop "evaluating" in OT, start small
You know this pattern. A control is identified, a team is assigned, a pilot is scoped, and then, a year and a half later, there is an excellent document but nothing on the network.
Waving this off as timidity on the part of the OT Cybersecurity team is unfair. They operate with almost no tolerance for downtime; engineering holds a genuine veto, and the possible consequence of being wrong is not a bad quarter, but a line stopped or a community without water. Studying something carefully before touching production is not a character flaw.
But the underlying arithmetic changed, and I do not think we have factored the change into it all.
For bad actors, network reconnaissance used to be expensive. It took a human with time, skill, and patience, so attackers had to choose viable targets, and most plants were never chosen. Those days are over. Scanning is now free, continuous, and universal, and the window between a disclosed vulnerability and a working exploit is now measured in hours. Meanwhile, OT patch cycles are measured in years. Those two curves on the graph have crossed and diverged, and they are not crossing back.
This means that a network being discoverable is no longer a probability but an inevitability. The question used to be whether an exposed asset would ever be found. The question is now “What date?”
An 18-month OT security evaluation used to be a precautionary measure. Now that’s eighteen months of someone else's attack schedule running while yours does not. Your exposure does not pause out of respect for your process.
All that said, the way out is NOT to move faster on the whole plant. Nobody should do that, and anyone telling you to move faster will be mysteriously absent when it goes wrong. The way out is to stop treating the entire plant network as the decision itself. Pick one cell. One line. One set of assets that already stop you sleeping, probably the unpatchable ones you reluctantly wrote off years ago. Protect those, learn what it actually does to your operations, and let that inform how you tackle the next one.
That is the only version of the project that ultimately provides the cumulative knowledge that the big, whole, single version would have required you to already have.
The climb is not the hardest part
I am honestly petrified about my upcoming half-marathon trail race. A thousand feet of elevation is going to hurt, and there is a decent chance I will walk part of it.
But climbing the mountain is not the hard part, and I know that now in a way I could not have known it two years ago. The hard part was not even that first 5K. It was taking the first step, just getting moving, and improving incrementally in ways I was barely aware of.
Every good thing you have ever built had a start that looked unimpressive from the outside and felt worse from the inside. My agentic marketing org was one page a week. My first race was a 5K, and I was slow at it. Whatever is sitting in your OT network environment right now, happily answering every passing network scan, is waiting on you for a decision that will not feel any more obvious next March than it does today.
The only way to finish is to start.
FAQs
Why is starting often the hardest part of an OT cybersecurity project?
OT teams operate in environments where downtime can stop production or interrupt essential services, so caution is justified. The problem arises when evaluation continues so long that exposed assets remain discoverable while attackers continue scanning. Starting with a limited, controlled scope creates the operational knowledge needed to make better security decisions.
Why should OT cybersecurity teams start with a small deployment?
A small deployment reduces the operational risk of making a plant-wide change while allowing teams to see how a security control behaves in their actual environment. Protecting one cell, production line, or group of critical assets provides real-world information that planning alone cannot produce.
Which OT assets should be protected first?
Start with a small group of high-risk assets, especially systems that are difficult or impossible to patch and that already create concern for the OT or cybersecurity team. The goal is not to secure the entire plant at once, but to protect a manageable area, learn from the deployment, and use those lessons to guide expansion.
Why is network discoverability a growing OT cybersecurity risk?
Automated network scanning has made reconnaissance inexpensive, continuous, and widespread. At the same time, many OT systems remain unpatched for long periods. That means a discoverable OT asset should increasingly be treated as something that will eventually be found rather than something that might be found.
What is wrong with an 18-month OT security evaluation?
Long evaluations may have made sense when reconnaissance and exploitation moved more slowly. Today, attackers can scan continuously while newly disclosed vulnerabilities can be weaponized quickly. An extended evaluation leaves existing exposure in place while the threat environment continues moving.
How can OT teams improve security without making risky plant-wide changes?
Instead of treating the entire plant as one decision, isolate a smaller security project. Select one cell, line, or set of vulnerable assets, apply the control there, observe the operational impact, correct what does not work, and then expand based on what the team has learned.
How To: Start an OT Cybersecurity Project Without Securing the Entire Plant at Once
1. Identify the OT security project that has been stuck in evaluation
Find the control, architecture change, or protection initiative that has been discussed repeatedly but has not reached production.
2. Reduce the scope
Do not make the entire plant network the first deployment. Choose one cell, one production line, or one clearly defined group of assets.
3. Prioritize the assets that create the most exposure
Consider starting with systems that are difficult to patch, outdated, highly exposed, or already causing concern for the OT team.
4. Protect the selected environment
Implement the security control only within the defined scope so the team can evaluate its real operational effect without introducing unnecessary plant-wide risk.
5. Observe what happens in production
Look for operational issues, incorrect assumptions, unexpected dependencies, and security gaps. These are often impossible to identify completely during planning.
6. Fix the process, not just the immediate problem
When something does not work as expected, determine whether the underlying configuration, policy, or deployment approach needs to change so the same issue does not repeat.
7. Use what you learned to expand
Apply the lessons from the first deployment to the next cell, line, or group of assets. Each step builds the operational knowledge required for broader OT protection.
8. Continue incrementally
The objective is not a perfect first deployment. It is a repeatable process that steadily reduces exposure while preserving the operational caution OT environments require.
Jaguar Land Rover’s cyberattack shut production for five weeks. The lesson: limit blast radius with network cloaking, segmentation, and verified access to OT.
Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.
Less than 8% of OT and ICS Companies Have Robust AI Deployment, According to new Nozomi Networks and BlastWave-Sponsored Takepoint Research
.svg)
.svg)
