Skip to content

Threat Model Versioning & Restoring

Threat models change as systems evolve. Devici automatically stores historical versions of every threat model, allowing you to review past states and restore earlier versions when needed.

Versioning helps teams track design evolution, understand how risk changes over time, and recover safely from mistakes.

Use this guide when managing long-lived threat models or collaborating across design changes.

How threat model versioning works

Devici automatically saves historical versions of a threat model as changes are made.

Each version captures the full state of the model at that point in time, including:

  • Elements and data flows
  • Trust boundaries
  • Attributes and mitigating attributes
  • Generated threats
  • Mitigation status

The current version represents the latest state of the threat model. All previous versions remain available as historical versions.

Tip

Versioning is especially valuable during early design, when models change frequently.

Viewing historical versions

Historical versions can be accessed from the Threat Model information drawer.

When you select a historical version:

  • The model opens in read-only mode
  • No changes can be made until the version is restored
  • You can review structure, threats, and mitigations as they existed at that time

This allows you to safely inspect earlier decisions without affecting the current model.

Restoring a historical version

To edit a historical version, it must first be restored.

What happens when a version is restored

When you restore a historical version:

  • The selected version becomes the new current version
  • The previously current version is moved to the historical list
  • No data is deleted from any version
  • All versions remain accessible

Versions are always listed with the current version first, followed by historical versions in descending date order.

Warning

Restoring a version replaces the current model state. Ensure the team understands the change before restoring.

Collaboration and version restores

When multiple users are collaborating on a threat model, restoring a version affects collaborators differently depending on their activity.

Active collaborators

If other users are actively working on the model at the time a version is restored:

  • They receive a notification that their version is outdated
  • They can choose to:
  • Switch immediately to the new current version, or
  • Continue working temporarily in the outdated version

If they continue working in the outdated version:

  • They have a limited time window to make changes
  • Any changes they make are saved as a new historical version

Inactive collaborators

For collaborators who are not actively editing the model:

  • The next time they open the threat model, they will see the new current version

This approach minimizes disruption while preserving all work.

When to restore a version

Restoring a previous version can be useful when:

  • A design change needs to be reverted
  • An experimental update produced unintended results
  • You want to re-evaluate a prior approach
  • A mistake was made during editing

Tip

Use version restoration as a recovery tool, not as a substitute for deliberate modeling decisions.

Best practices for versioning

To use versioning effectively:

  • Restore versions intentionally and communicate changes
  • Use the Threat Model Health Score to assess readiness before and after restores
  • Treat restored versions as a new iteration, not a rollback of responsibility
  • Re-r