DTSECOPEN DIGITAL TWIN SECURITY LAB
FREE SECURITY ASSESSMENT

DTSEC-25 Digital Twin Security Assessment

Twenty-five questions provide a fast, educational view of digital-twin security maturity. Answers and scoring stay in this browser and are never submitted or stored.

Not certification

This is an educational maturity assessment, not a certification, audit, compliance determination, safety case, or guarantee of security.

CURRENT RESULT0/ 100
MATURITYUnknown

0 of 25 answered

0 Not in place / unknown1 Ad hoc2 Partly managed3 Consistent4 Verified and improved
  1. 01Architecture documentationCurrent diagrams identify physical assets, data flows, trust boundaries, integrations, and paths to physical effect.
  2. 02Asset inventoryDevices, gateways, services, models, APIs, identities, owners, versions, and dependencies are inventoried.
  3. 03Device identitySensors, controllers, gateways, and edge devices have unique, managed identities.
  4. 04AuthenticationMachine and human access uses authentication proportionate to consequence.
  5. 05AuthorizationPolicy limits who or what may read state, alter models, invoke APIs, and issue commands.
  6. 06Sensor integrityCalibration, configuration, tamper evidence, and plausibility checks protect sensing.
  7. 07Telemetry integrityMessages are protected against modification, substitution, replay, and downgrade.
  8. 08Data provenanceOrigin, transformation, custody, quality, and time context remain traceable.
  9. 09Transport securityCommunication is protected and protocol choices account for operational constraints.
  10. 10API securityAPIs are inventoried, authenticated, authorized, validated, constrained, and logged.
  11. 11Edge securityGateways and edge runtimes are hardened, monitored, isolated, and recoverable.
  12. 12Firmware securityFirmware authenticity, versions, vulnerabilities, and update procedures are managed.
  13. 13SegmentationCommunication between enterprise, twin, vendor, edge, and control environments is bounded.
  14. 14Twin identityEach twin instance is uniquely identified and bound to its intended asset, purpose, and owner.
  15. 15Model integrityModels, parameters, dependencies, and configurations are signed or otherwise integrity-verified.
  16. 16Model versioningApproved versions, test evidence, lineage, rollback, and deployment state are traceable.
  17. 17Synchronization integrityFreshness, ordering, trusted time, disagreement, and degraded-state behavior are defined.
  18. 18AI/ML controlsTraining data, inference, drift, human oversight, limitations, and failure behavior are governed.
  19. 19Physical-command authorizationCommands require independent authorization, limits, interlocks, and safe-state logic.
  20. 20MonitoringCyber events are correlated with process behavior, model changes, data quality, and identity use.
  21. 21LoggingLogs can reconstruct source data, transformations, decisions, approvals, and commands.
  22. 22Vendor accessSupplier access is time-bounded, attributable, approved, monitored, and removable.
  23. 23Supply-chain controlsSoftware, firmware, models, services, components, and updates have traceable assurance.
  24. 24Incident responsePlans address physical safety, evidence, desynchronization, compromised models, and recovery authority.
  25. 25DecommissioningIdentities, data flows, integrations, access, retained data, and physical bindings are retired deliberately.