Digital Twin Risk Model
Build a digital twin of an insured's OT/ICS, IoT, and physical-system footprint and model how a cyber event would propagate. Purpose-built for cyber underwriters and brokers writing manufacturing, energy, smart-city, and connected-product risk.
Why underwriters need a digital twin
A digital twin is a software mirror of a physical asset, process, or whole organization. When an attacker compromises the digital twin — by bypassing auth, injecting policy, or replaying tampered state — the change can cascade into the physical world: a pressure valve that reports "closed" while it is "open" is a safety incident, not a data-integrity event.
For a cyber underwriter, that means the loss magnitude is no longer bounded by data breach costs. A successful digital-twin compromise in OT/ICS or connected-product manufacturing can produce property damage, bodily injury, environmental release, and supply-chain shutdown — categories that most cyber policies exclude and that traditional IT cyber questionnaires do not capture.
Risk dimensions to model
Authentication & authorization
Does the platform enforce auth on all twin-modification endpoints? Are pre-authenticated reverse-proxy paths documented and gated? Are service-to-service tokens short-lived and scoped?
Policy & state injection
Can a low-privilege tenant escalate by importing a crafted policy? Are state transitions validated against the physical model? Can replayed messages shift the twin out of safe state?
WebSocket & session hygiene
Do long-lived connections revalidate identity? Are heartbeat messages signed? Can a stolen JWT be downgraded to a less-protected channel?
Physical blast radius
What does the twin control? A smart meter caps loss at revenue; a robotic arm or safety interlock raises it to injury and asset damage. The underwriting model must price the worst case, not the median.
NIS2 / CRA exposure
Under NIS2, manufacturing entities face penalties of up to €10M or 2% of global turnover. Under the Cyber Resilience Act (CRA), manufacturers of connected products bear single-reporting-platform (SRP) obligations with a 24-hour notification clock for actively exploited vulnerabilities, a 72-hour assessment window, and a 14-day final-report deadline. A digital twin that controls a CRA-scoped product inherits these reporting clocks — and the cyber policy must be checked for retroactive SRP-related defence-cost coverage.
Underwriting workflow
- 1. Identify twin footprint. Map every digital twin deployed in the insured's environment: framework (Eclipse Ditto, Azure DT, custom), asset class, and physical control surface.
- 2. Score auth & policy surface. Probe for missing JWT enforcement, policy-import escalation, and WebSocket bypass. Treat any bypass on a modification endpoint as a control deficiency on the application questionnaire.
- 3. Price worst-case loss. Use FAIR LM bands: $2M (consumer IoT) → $200M+ (manufacturing / energy / grid). Multiply by twin count and correlate by shared platform CVE.
- 4. Apply SRP / NIS2 modifier. Check whether the insured can meet 24h / 72h / 14d clocks. If not, add coverage restriction for regulatory-fine indemnity or impose attestation requirement.
- 5. Recommend hardening. Use the findings to drive premium credit for auth hardening, immutable audit log, and tested runbook.
Related Resiliently tools
- • Incident Cost Estimator — model the financial loss from a twin-led OT compromise.
- • Cyber Accumulation Visualizer — quantify vendor-platform correlation across a portfolio.
- • NIS2 Compliance Checker — confirm SRP-readiness posture.
- • The Underwriting Table — practice pricing dossiers with realistic company profiles.