<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@graph": [
   {
     "@type": "FAQPage",
     "mainEntity": [
       {
         "@type": "Question",
         "name": "Why is there no finish line in OT cybersecurity?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "OT cybersecurity is not a project that becomes permanently complete. Attackers continue scanning, vulnerabilities continue appearing, configurations change, and exceptions accumulate over time. Instead of measuring security only by completed projects or audits, OT teams need an ongoing process for making the environment incrementally harder to discover, access, and traverse."
         }
       },
       {
         "@type": "Question",
         "name": "What does “one percent better” mean in OT security?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "“One percent better” is a mindset rather than a precise risk metric. It means making small, verifiable security improvements such as cloaking one device, eliminating one password, removing one unnecessary open port, or closing one lateral movement path. Each improvement reduces something an attacker can discover or use."
         }
       },
       {
         "@type": "Question",
         "name": "How can OT teams measure continuous security improvement?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Focus on conditions that can be verified instead of abstract risk scores. For example, determine whether an unauthorized user can discover or communicate with a specific OT device. That answer can be tested directly. Over time, teams can track how many assets no longer respond to unauthorized scans or connections."
         }
       },
       {
         "@type": "Question",
         "name": "Why can’t an OT compliance audit be treated as the finish line?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "An audit has a completion date, but attackers do not. Passing an audit confirms conditions at a particular point in time. Configuration changes, new vulnerabilities, temporary exceptions, and other operational changes can alter the environment afterward, which is why verification must continue beyond the audit."
         }
       },
       {
         "@type": "Question",
         "name": "Why does architecture matter for continuous OT security?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Policies depend on people repeatedly following them. Architecture can make a security condition inherent to the environment. For example, an OT asset that is not discoverable by unauthorized users does not depend on someone remembering to make the correct decision every day. However, architectural controls still need ongoing verification because configurations and exceptions can change."
         }
       },
       {
         "@type": "Question",
         "name": "How does network cloaking support continuous OT security improvement?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Network cloaking reduces what unauthorized users and scanners can discover. Instead of exposing an OT device and relying only on downstream defenses, cloaking can make the device unavailable to unauthorized reconnaissance. For a small OT team, improving security may therefore be as practical as making one additional device undiscoverable this week."
         }
       }
     ]
   },
   {
     "@type": "HowTo",
     "name": "How to Make Your OT Network One Percent Better",
     "description": "A practical process for continuously improving OT cybersecurity by reducing asset exposure, removing unnecessary trust, applying network cloaking, and verifying each improvement.",
     "step": [
       {
         "@type": "HowToStep",
         "position": 1,
         "name": "Choose one OT asset",
         "text": "Do not begin by trying to redesign the entire security program. Select one PLC, HMI, controller, server, or other OT asset that can be improved."
       },
       {
         "@type": "HowToStep",
         "position": 2,
         "name": "Test whether unauthorized users can discover it",
         "text": "Determine whether the asset responds to scans, probes, or connection attempts that should not be authorized. Establish a clear starting condition: discoverable or not discoverable."
       },
       {
         "@type": "HowToStep",
         "position": 3,
         "name": "Reduce unnecessary exposure",
         "text": "Remove unnecessary open ports, services, inbound connections, or other paths that allow the asset to be discovered or reached."
       },
       {
         "@type": "HowToStep",
         "position": 4,
         "name": "Cloak the asset from unauthorized users",
         "text": "Use network architecture that prevents unauthorized systems from discovering or initiating communication with the asset while preserving access for approved users and systems."
       },
       {
         "@type": "HowToStep",
         "position": 5,
         "name": "Remove unnecessary trust",
         "text": "Review passwords, broad network access, and lateral communication paths associated with the asset. Eliminate any access or connectivity that is not required for operations."
       },
       {
         "@type": "HowToStep",
         "position": 6,
         "name": "Verify the new condition",
         "text": "Test again from an unauthorized perspective. The goal is a binary result: the asset should no longer respond where access is not permitted."
       },
       {
         "@type": "HowToStep",
         "position": 7,
         "name": "Record the improvement",
         "text": "Document what changed and what condition is now true. Treat the improvement as an architectural property to preserve, not simply a completed project milestone."
       },
       {
         "@type": "HowToStep",
         "position": 8,
         "name": "Repeat with the next asset",
         "text": "Choose another device, account, connection, or segment and repeat the process. There may be no final state for OT security, but the network can still become measurably harder to discover and attack one improvement at a time."
       }
     ]
   }
 ]
}
</script>

June 4, 2025
September 22, 2026
 —  
Blog

There Is No "Finish Line" in OT. There Is "One Percent Better."

There Is No "Finish Line" in OT. There Is "One Percent Better."

There is no finish line.

You have heard that sentence before, and almost certainly from somebody who wanted to sell you something. I am going to argue that it is true anyway, and then I will explain why it is usually said to you in bad faith.

I am training for my second half marathon, on a trail course that climbs more than 1,000 feet. Two years ago, the longest distance I had committed to was a 5K, and I was slow even at that distance.

Here is what I did not understand when I started. The race is not what you think about when you train. The race is a date on a calendar. What I actually think about is my run for Tuesday. Or Wednesday. Or the long run on Sunday.

A race has a finish line. Training does not.

These are two different activities, and I had them confused for most of my adult life.

A race gives you a date, a distance, and a completion criterion. You cross the line, somebody hands you a medal, and the thing is over in the only sense that matters: you can now stop. That is a real and satisfying shape, and it is the shape almost every project at work is given.

Training has none of that. There is no state you arrive at where the schedule is no longer necessary. Crossing a finish line does not change what your body can do on Wednesday morning, and the fitness you spent six months building begins to fade within weeks of stopping. Runners know this, and it does not depress them, because they are not measuring against completion. They are measuring against last week.

I made an argument in last week’s article that the hard part of anything is starting it, and that readiness is something starting produces rather than something you go and acquire first. A reader named Thomas Drews pushed back on the framing. His words: "The title of this post implies that there will be a finish, once you started. IMHO this is wrong. It's a race without a finish line."

He is right, and he is right in a way that strengthens the point I was trying to make, without my realizing it, as I wrote the initial article.

What I built two years ago was not a 5K result. It was a training schedule. The race was the excuse that produced the schedule, and the schedule is the asset. I had been describing the excuse as the goal.

Continuous Improvement is also a business model

I work in cybersecurity, and I know what the phrase "there is no finish line" gets used for.

It is the sentence that justifies the renewal. It is why the invoice is annual, why the posture is permanent, and why no vendor has ever told a customer that a problem is solved and they should stop paying for it. Said by the right person at the right point in the budget cycle, "security is a journey, not a destination" is not a philosophy. It is a pricing model.

So it is worth separating the two very different things bundled inside that sentence.

The first is real. The adversary does not stop, does not finish, and has no completion criterion. Nothing you deploy makes that untrue.

The second is a choice. A control that bills you continuously must be justified continuously, and each year it will be weighed against something else. The controls that survive that conversation are rarely the ones carrying the most weight. They are the ones whose value is easiest to put on a slide.

Those are not the same claim. The adversary being permanent does not mean your spending has to scale with their patience. It means you should be extremely interested in which of your controls stay "done" when nobody is watching them.

OT security is a project. The attacker runs a process.

You know the shape of an OT security program. It has a name, a start date, a target completion, a budget line, a steering committee, and a slide with a green bar on it. In the end, the committee disbands, and the bar reaches 100%.

Compliance makes this worse rather than better, and I say that as someone who thinks the regulations are broadly right. An audit has a date. Preparing for one feels like training, and passing it feels like finishing. The two months after an audit are the quietest months in any security program I have ever seen.

Meanwhile, the arithmetic on the other side changed without announcing itself.

Reconnaissance used to be expensive. Finding an exposed asset took a human with time, skill, and patience, so attackers chose their targets, and most plants were never chosen. That is over. Scanning is now free, continuous, and universal. At the same time, the window between a disclosed vulnerability and a working exploit collapsed to hours, while OT patch cycles are still measured in years and, for a controller built in 2009, in never.

Which means being discoverable stopped being a probability and became a schedule. Not whether an exposed asset gets found. What date.

There is no version of that sentence with a completion criterion in it. You are running a project against a process, and the mismatch is not about effort or funding or how good your team is. It is about shape.

One percent is the only goal that survives having no finish line

If you take the finish line away, you have to put something in its place, or you have taken away the only thing that told anyone whether the work was going well. I tend to think of my finish lines being the next starting line, but I wouldn't consider myself normal, either.

Training already solved this, and the idea has a name that comes from cycling rather than from security. Dave Brailsford took over British Cycling in 2003 and called it the aggregation of marginal gains: the one percent margin for improvement in everything you do. Not one enormous intervention. Every small thing, slightly better, all of them at once.

Which brings us back to the premise: One Percent Better.

Every single thing you do that removes something from an attacker's input leaves your network permanently better than it was that morning. One asset that no longer responds to a stranger's scan. One password that has been eliminated, and can no longer be stolen, phished, or replayed. One lateral path that is not there to be traversed. One inbound port that no longer has to stand open waiting to be found.

None of those is a program. Each one is a device, an account, a segment, an afternoon.

You already know the familiar arithmetic. One percent better every day compounds to roughly thirty-seven times better over a year, and one percent worse every day leaves you at about three percent of where you started. OT security doesn't compound daily, and the exponent is a party trick. Forward motion and direction are not.

"But is it really 1%?" is likely what you are saying to yourself.

You cannot measure a one percent reduction in risk. Nobody can. Anyone who hands you a risk score with a decimal point in it is selling you the decimal point, and a CISO who has been in this industry longer than ten minutes knows it. One percent is a posture, not a metric.

But there is something underneath it you can verify, and it is binary. Does this device answer a stranger who asks it a question, yes or no? That has an answer; it has the same answer on Tuesday, and you can check it yourself. Count the ones where the answer is no. That number moves in one direction, and it is closer to a real scoreboard than any maturity rating I have ever been shown.

Which brings me to the condition, because one percent only compounds if the gains stay.

A gain that decays is a rental. Most of what gets counted as security improvement is a milestone, something you achieved, sitting in the past tense, decaying the moment attention moves elsewhere. What you want instead is a property, something true in the present tense, without anyone maintaining enthusiasm for it. An asset that does not respond to unauthorized scans does not respond during the quiet two months after the audit, or when the engineer who configured it has left the company. It is not behaving well. It has no opinion.

That is why architecture beats policy, and it is not a claim about which is smarter. Policy depends on people continuing to choose it, and people stop choosing things. Architecture only has to be chosen once.

Nothing is permanent. Architecture gets misconfigured, exceptions get granted at 2am and never revoked, and a property nobody verifies is a belief with better posture. Verification never ends.

But here is what one percent does for OT. Most OT security teams I talk to are one or two people holding a scope written for nine. Told that the work is infinite and handed a program, that is crushing. Told that the work is infinite and handed one percent, it is the opposite, because it means nothing you do is wasted, and nothing is too small to count. You cannot execute a nine-person program. You can cloak one device this week.

The race is just a date

I am going to cross the line on that trail course, and I will be extremely pleased with myself. The following Tuesday, there will still be a run scheduled.

That is not a disappointment. It means I am at my next starting point, and I will continue to get better.

Thomas is right. There is no finish line. There is only next week, and whether the network is one device better than it was.

FAQs

Why is there no finish line in OT cybersecurity?

OT cybersecurity is not a project that becomes permanently complete. Attackers continue scanning, vulnerabilities continue appearing, configurations change, and exceptions accumulate over time. Instead of measuring security only by completed projects or audits, OT teams need an ongoing process for making the environment incrementally harder to discover, access, and traverse.

What does “one percent better” mean in OT security?

“One percent better” is a mindset rather than a precise risk metric. It means making small, verifiable security improvements such as cloaking one device, eliminating one password, removing one unnecessary open port, or closing one lateral movement path. Each improvement reduces something an attacker can discover or use.

How can OT teams measure continuous security improvement?

Focus on conditions that can be verified instead of abstract risk scores. For example, determine whether an unauthorized user can discover or communicate with a specific OT device. That answer can be tested directly. Over time, teams can track how many assets no longer respond to unauthorized scans or connections.

Why can’t an OT compliance audit be treated as the finish line?

An audit has a completion date, but attackers do not. Passing an audit confirms conditions at a particular point in time. Configuration changes, new vulnerabilities, temporary exceptions, and other operational changes can alter the environment afterward, which is why verification must continue beyond the audit.

Why does architecture matter for continuous OT security?

Policies depend on people repeatedly following them. Architecture can make a security condition inherent to the environment. For example, an OT asset that is not discoverable by unauthorized users does not depend on someone remembering to make the correct decision every day. However, architectural controls still need ongoing verification because configurations and exceptions can change.

How does network cloaking support continuous OT security improvement?

Network cloaking reduces what unauthorized users and scanners can discover. Instead of exposing an OT device and relying only on downstream defenses, cloaking can make the device unavailable to unauthorized reconnaissance. For a small OT team, improving security may therefore be as practical as making one additional device undiscoverable this week.

How To: Make Your OT Network One Percent Better

1. Choose one OT asset

Do not begin by trying to redesign the entire security program. Select one PLC, HMI, controller, server, or other OT asset that can be improved.

2. Test whether unauthorized users can discover it

Determine whether the asset responds to scans, probes, or connection attempts that should not be authorized. Establish a clear starting condition: discoverable or not discoverable.

3. Reduce unnecessary exposure

Remove unnecessary open ports, services, inbound connections, or other paths that allow the asset to be discovered or reached.

4. Cloak the asset from unauthorized users

Use network architecture that prevents unauthorized systems from discovering or initiating communication with the asset while preserving access for approved users and systems.

5. Remove unnecessary trust

Review passwords, broad network access, and lateral communication paths associated with the asset. Eliminate any access or connectivity that is not required for operations.

6. Verify the new condition

Test again from an unauthorized perspective. The goal is a binary result: the asset should no longer respond where access is not permitted.

7. Record the improvement

Document what changed and what condition is now true. Treat the improvement as an architectural property to preserve, not simply a completed project milestone.

8. Repeat with the next asset

Choose another device, account, connection, or segment and repeat the process. There may be no final state for OT security, but the network can still become measurably harder to discover and attack one improvement at a time.

OT Secure Remote Access
Network Cloaking
Network Segmentation

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.