The Login Is Real. The Device Isn't. BlastShield 2.0 Can Tell the Difference.

An attacker with your contractor's password looks exactly like your contractor. In the Inside BlastShield 2.0 webinar, BlastWave's CEO, CMO, and Solutions Architect showed what changes when the network checks the device, not just the login.

Watch the replay:

Or skip ahead: schedule a demo

650 million+ protected device hours. Zero successful breaches. Including professional penetration tests.

What is BlastShield 2.0? BlastShield 2.0 is a major release of BlastWave's OT secure remote access and network cloaking platform. It makes the device an independent access factor alongside the user's identity (device posture enforcement), hides the IT systems that connect into OT (Agent cloaking and self-isolation), protects session keys against harvest-now, decrypt-later attacks (hybrid post-quantum key exchange), and makes remote support sharper and mobile (BlastAccess). It upgrades without taking your network down.

Why Isn't a Valid Login Enough Anymore?

In the webinar, BlastWave CEO Tom Sego explained that AI has changed the things defenders used to rely on, and most of it happened in the last six months:

1. Exploits are built at machine speed. Frontier AI models can now chain vulnerabilities into sophisticated exploits that humans couldn't produce at scale.
2. Reconnaissance is automated. Finding vulnerable systems, the first step in every attack chain, no longer takes a skilled human. Small operators get found just as easily as large ones.
3. The patch window is closing. The time defenders once had to inventory assets, find what needs patching, and deploy fixes is shrinking toward zero.
4. Credentials are still the easiest way in. In Dragos's incident-response casework, 73% of all-time OT engagements involved compromised VPN or jumphost credentials.

“No matter how small you are, AI is going to find you.”

— Tom Sego, CEO, BlastWave

When an attacker can find you in minutes and sign in with a real password, checking who is signing in isn't enough. Authentication is often the weakest point in the attack chain. BlastShield 2.0 makes the device prove itself too.

How Does BlastShield 2.0 Stop an Attacker With a Real Password?

BlastShield already binds every login to an enrolled device with its own key. Version 2.0 adds a second question at every login: is this device one you admitted, and is it healthy enough to trust?

1. A stolen password on an unknown laptop? Refused. (Device Posture Enforcement)

Device health becomes an independent access factor, alongside the user's identity. You choose how new devices are admitted: accept them automatically, hold them for admin approval, or admit only devices that match a security posture you define. Posture rules cover Windows, macOS, Linux, iOS, and Android, with checks like Secure Boot, hardware-backed device keys, active antivirus, and minimum OS versions.

A phished password can't open a session from an attacker's laptop, and a contractor's unmanaged machine doesn't inherit the contractor's access. When a vendor genuinely needs in at 2 a.m. from a device you've never seen, admin approval gives you just-in-time access: the request appears in the Orchestrator, and you let them in in real time.

2. A device that drifts mid-session? Cut off. (Continuous Posture Monitoring)

Posture is checked continuously, not just at sign-in. If someone turns off antivirus or disk encryption while connected, that device loses access to every policy that requires compliance, including the session in progress. No administrator has to step in. Continuous verification is exactly what the Department of War and federal agencies are pushing for.

3. A login from the wrong country? Flagged. (Location Check)

In BlastShield 2.0.2, the Authenticator compares where the user's phone is connecting from with the device running the BlastShield Client. A laptop in one country and a phone in another is a warning sign: the user can cancel the connection, and administrators can kill it from the Orchestrator in real time.

4. An IT endpoint that answers scans? Silent. (Agent Cloaking and Self-Isolation)

Cloaking now extends to endpoints running the optional BlastShield Agent. A cloaked host silently drops unauthenticated traffic, so scanners can't tell it from empty address space. With self-isolation, it accepts inbound connections only over BlastShield. That closes off the IT-side systems attackers use as a path into the plant.

5. Traffic recorded today, decrypted later? Protected. (Post-Quantum Key Exchange)

Attackers can record encrypted sessions now and decrypt them once the computing power exists. BlastShield 2.0 uses a hybrid ECDHE and ML-KEM key exchange, pairing a NIST-standardized post-quantum algorithm with the classical exchange. Administrators can require it from the Orchestrator's network settings. As CMO Cam Cullen noted, federal agencies and defense contractors should expect post-quantum cryptography to be required of them soon.

Bonus: remote access people will actually use. (BlastAccess and Authorized Resources)

BlastAccess hybrid rendering sends only the moving parts of the screen as video, so setpoints, tag names, and alarm text stay sharp, even over low-bandwidth links. It now runs on iPhone, iPad, and Android phones and tablets with the BlastShield Client and Authenticator, and in-session chat lets administrators guide users over the shoulder. Sessions can be read-only and are recorded. The new Authorized Resources view shows users every system they're allowed to reach, with one-click ping and remote desktop.

What Did the Webinar Reveal About Real Attacks?

One registrant asked how BlastShield 2.0 would hold up against the recent attacks on supermarket refrigeration systems. Cam's answer: the devices attackers used would have failed the device check, so a connection from overseas would have been refused even with stolen passwords. Cloaked systems wouldn't have shown up in a scan. And a contractor account limited to read-only BlastAccess couldn't have changed anything, with an administrator able to watch the session.

Tom added a recent penetration test report. In phase one, the tester found seven vulnerabilities and ranked them by severity. In phase two, the customer deployed BlastShield, and every one of them became undiscoverable.

“If you're cloaking those assets so they are undiscoverable unless you're cryptographically authenticated, the adversary's not going to see anything.”

— Tom Sego, CEO, BlastWave

We'll be straight with you, and Tom said it himself: BlastWave doesn't claim to be unhackable. But across more than 650 million device hours in 5,000 locations and 21 countries, including sophisticated pen tests, no one has successfully breached BlastShield. Version 2.0 raises the bar again, because the adversary isn't standing still.

Can You Upgrade Without Taking OT Offline?

Yes. Solutions Architect Joe Baxter walked through it during the Q&A:

• Schedule it. Download the firmware in the Orchestrator and set the install for your maintenance window, like 2 a.m. on a Sunday.
• Keep running. The Orchestrator restarts in about 20 to 30 seconds. Networks keep running exactly as configured; only new sign-ins pause.
• Roll through high availability. With multiple Orchestrators or high-availability Gateway pairs, nodes update one at a time, so service never stops.
• Bring users along. Existing clients keep connecting, and the Client prompts users when an update is available.
• Automate it. Device posture settings are available through the BlastShield API.

As Joe put it, downtime for OT customers is the kiss of death. The upgrade path is built around that.

See it for yourself: schedule a live demo and watch us scan a protected controller, then have an authorized operator reach the same device: blastwave.com/schedule-a-demo

The login can be real. The device still has to earn its way in.

‍