The conventional wisdom: When a third-party component lacks HTTPS support, you're stuck with insecure HTTP until the vendor fixes it. Your hands are tied.
This belief surfaces in every OT security assessment I review. Teams point to vendor limitations as immutable constraints. "The Digipede server doesn't support HTTPS," they say, as if that settles the matter. It doesn't.
Hitachi Energy's recent disclosure about PROMOD V versions 1.0.10 and earlier (CVE-2026-10763, CVSS 7.1) illustrates exactly what's wrong with this thinking. The vulnerability stems from HTTP transmission due to third-party server limitations. But here's what the advisory doesn't say: this wasn't inevitable.
Rethinking Vendor Limitations
Blaming the third-party component treats architecture as fixed when it's actually a series of choices. You chose to integrate that component. You chose the network topology. You chose not to implement compensating controls.
The "vendor doesn't support HTTPS" excuse collapses under basic architectural scrutiny. You have options:
Terminate TLS at the boundary. Deploy a reverse proxy that accepts HTTPS from clients and translates to HTTP only within a microsegmented network zone. The cleartext traffic never crosses a network boundary an attacker can reach. This is standard practice in web application architectures, yet somehow becomes "impossible" when teams discuss industrial control systems.
Encrypt the transport layer differently. If application-layer HTTPS isn't available, IPsec or WireGuard can encrypt all traffic between specific endpoints. You're not limited to the protocols the application vendor chose.
Isolate the insecure component completely. Air-gap it from networks that handle credentials or sensitive operational data. If you must connect it, use a data diode or unidirectional gateway. Yes, this limits functionality. That's the point.
The PROMOD V case reveals a deeper problem: teams conflate "the application doesn't support HTTPS" with "we cannot secure this communication." These aren't the same statement. The first describes a product limitation. The second describes an architecture failure.
Understanding the Risks
Look at what CVSS 7.1 actually means in this context. The vulnerability allows credential theft, session hijacking, and unauthorized access through network interception. The attack vector is network-based (AV:N), requires low complexity (AC:L), and needs no privileges (PR:N). An attacker on the same network segment can capture everything in transit.
Now consider typical OT network architecture. PROMOD V handles power system modeling and analysis. That means it processes grid topology data, load forecasts, and operational constraints. An attacker who intercepts this communication learns your network's weak points, generation capacity, and contingency plans.
The "general mitigation factors" in the advisory recommend firewalls, network segmentation, and limiting internet exposure. These are baseline hygiene, not compensating controls for cleartext protocols. A firewall doesn't encrypt your traffic. Network segmentation doesn't protect against insider threats or compromised endpoints within the segment.
CISA's republication of this advisory signals something important: federal agencies consider this vulnerability significant enough to warrant broad notification. Yet the recommended practices focus on perimeter defense, not the fundamental protocol weakness.
Proactive Steps to Take
Start with threat modeling, not vendor limitations. Map the data flows. Identify what an attacker gains by intercepting each communication path. Then design controls that address those specific risks. If the vendor product can't implement those controls natively, you implement them in the architecture.
Implement defense-in-depth that assumes HTTP interception. Since you can't eliminate the cleartext protocol immediately, build your security model around the assumption that an attacker can read it. Use mutual TLS certificate authentication at the network edge. Implement application-level signing for critical commands. Deploy network behavior analytics that detect unusual access patterns even when the protocol itself is compromised.
Set hard deadlines for third-party upgrades. When you discover a vendor component lacks HTTPS support, you don't accept it indefinitely. You establish a 90-day timeline to implement compensating controls and a 12-month timeline to replace or upgrade the component. Document this in your risk register with executive visibility.
Audit your other third-party integrations now. PROMOD V isn't unique. Review every vendor product in your environment. Which ones use cleartext protocols? Which ones transmit credentials or sensitive data? You'll find more than you expect. Prioritize them by data sensitivity and network exposure, then systematically address each one.
Rewrite your vendor security requirements. Your RFP process should explicitly reject products that use HTTP for any communication involving credentials or sensitive data. No exceptions for "industry standard" or "widely deployed" products. If the vendor claims HTTPS isn't possible in your operational environment, that's a deal-breaker, not a negotiating point.
Recognizing Genuine Constraints
Third-party dependencies do create real constraints in specific scenarios. If you're operating a safety-instrumented system certified under IEC 61508, you can't arbitrarily insert proxies or encryption layers without invalidating the certification. The change management process for these systems is deliberately rigid.
Similarly, if you're running legacy equipment with hard-coded IP addresses and no ability to route through a proxy, your architectural options narrow considerably. A 20-year-old RTU with firmware that can't be updated presents genuine limitations.
But here's the critical distinction: these constraints should drive your risk acceptance decision, not your security architecture. If you genuinely cannot implement HTTPS or equivalent transport security, you document that risk, present it to executive leadership with the specific dollar impact of potential exploitation, and get formal acceptance. You don't just shrug and move on.
The PROMOD V disclosure should prompt every CISO to ask: where else are we accepting vendor limitations as immutable? Where are we treating architecture choices as vendor constraints? The answers will be uncomfortable, but they're necessary.
Your third-party dependencies don't excuse insecure protocols. They reveal where you've prioritized convenience over security architecture. Fix that, and the vendor limitations become far less limiting.
