FAQ

Enablement

What licenses are required?

Active Devici license and active SD Elements license. Import from Devici is included with both products.

Does enabling Import from Devici change anything in existing SD Elements projects?

Existing survey-driven projects are not modified — survey answers, manually added Components, manually added Countermeasures, and tracker tickets are all preserved as-is. The only change visible on existing projects after the flag is enabled is the addition of a Devici tab in the project navigation, which is empty until a user uploads an OTM file. A project can use the survey, the OTM import, or both — they feed the same attribute pool.

Does Import from Devici introduce any new privileges?

No. The integration uses the existing SD Elements global and project role model. Enabling the feature flag uses the Manage Features permission; importing a Devici threat model uses the Edit Project Survey and Add Project Countermeasure project roles. See Permissions.

Behavior and data

Where does the data flow?

The customer initiates an export in Devici, which produces an OTM file on the customer’s local machine. The customer uploads that OTM file into SD Elements — either from the project’s Get Started Modal (the Import from a Devici file option) or from the project’s Devici tab — by clicking the paperclip icon and selecting the file. SD Elements imports the OTM and generates Countermeasures from the imported attributes. Generated Countermeasures land on the SD Elements project and the existing Issue Tracker configuration pushes them to Jira, GitHub, or Azure DevOps.

SD Elements does not connect directly to the Devici workspace. The data path is: Devici → user’s browser (export) → user’s browser (upload) → SD Elements. The OTM file is the only artifact that crosses between the two products.

The Devici workspace and the SD Elements workspace remain the systems of record for their respective domains. Nothing is duplicated; the OTM document is the contract.

Does Import from Devici work with custom Devici codex content?

Yes. Built-in Devici codex content always has a matching equivalent in the SD Elements Library (Security Compass maintains the two in alignment at the product level), so built-in attributes and mitigations are imported automatically. Anything custom — content your organization authored in your Devici workspace, not part of the built-in codex — becomes a project-specific custom Countermeasure tagged devici on the SDE side. The Devici mitigation detail and the threat it addresses render inside the Countermeasure’s Solution section. There is no manual reconciliation, no Gap Review, and no ref_id alignment work for the customer to do.

See How Devici content maps.

Which compliance frameworks are supported on day one?

Every framework SD Elements already supports — PCI DSS 4.0, SOC 2, NIST 800-53 Rev 5, HIPAA, ISO 27001, GDPR, plus any custom framework the customer maintains. Import from Devici does not introduce a new mapping layer; it adds an input path to the existing one.

Does the import overwrite manually edited Countermeasures?

No. Any Countermeasure that a user previously transitioned (for example to Implemented or Not Applicable) retains its manual status across re-imports. The re-import only adds, refreshes, or retires Countermeasures based on what changed in the source Devici model — it does not reset status. See How Countermeasure statuses are handled.

How do model updates propagate?

The customer re-exports the threat model from Devici, opens the project’s Devici tab, clicks the re-import icon near the top of the embedded canvas, and selects the new OTM file. SD Elements processes the file automatically using the same additive behavior as the first import: net-new attributes are added to the project’s attribute pool, net-new custom mitigations become custom Countermeasures tagged devici, and Countermeasures that are no longer triggered are marked Retired. Existing tracker tickets are not deleted.

There are three supported iteration patterns — incremental re-import (default), scope-on-the-Devici-side, and clean-slate reset. See Best practices for iterating on a model for the trade-offs and a decision guide.

What happens if the source threat model is deleted in Devici?

Nothing changes on the SD Elements side. Because Import from Devici is file-based and SD Elements does not maintain a live connection to the Devici workspace, the SD Elements project has no way to know the source was deleted. The previously imported attributes, the Countermeasures generated from them, and the embedded diagram all remain on the SD Elements project unchanged until a user explicitly removes them. To remove the SDE-side content after a source deletion, use Remove Devici Content on the project’s Devici tab — see Removing imported Devici content.

What happens if I remove the Devici content from an SD Elements project?

Remove Devici Content deletes everything an Import from Devici operation wrote to the project:

  • Every attribute that was added to the project’s attribute pool by a Devici import.

  • Every Countermeasure generated from those attributes.

  • The embedded Devici diagram on the Devici tab.

Manually-set attributes, survey-driven attributes, survey-driven Countermeasures, and any Components on the project are not affected. Tracker tickets in Jira / GitHub / Azure DevOps are not deleted; they remain in your tracker with their last known state and become orphaned references. This is the canonical cleanup operation — see Removing imported Devici content.

Can two SD Elements projects import from the same Devici threat model?

Yes. The OTM document is the input contract — any project on the tenant can upload the same OTM file. This is useful when one Devici model spans multiple SD Elements projects (for example, a platform model used by several application teams).

Will manual Countermeasures or survey answers be removed by a Devici import?

No. Import from Devici only writes attributes to the project’s attribute pool and only adds, updates, or retires Countermeasures triggered by those attributes. Manually added Components, manually answered survey questions, and Countermeasures triggered by survey-driven attributes are not modified — though if a survey-driven Countermeasure and a Devici-driven Countermeasure happen to be the same Countermeasure (because the same attribute is set by both paths), the Countermeasure is unified, not duplicated.

Deployment

Does Import from Devici work on on-premise SD Elements?

Yes. SaaS, on-premise, and air-gapped deployments are all fully supported with the same workflow. Because Import from Devici is file-based, there is no difference in capability between the three.

Does Import from Devici work in air-gapped deployments?

Yes, with no special configuration. The user exports the OTM file from Devici on a machine that can reach the Devici workspace, transfers the file into the air-gapped environment using whatever process the customer normally uses for file transfer in or out, and uploads it on the SD Elements Devici tab.

Does Import from Devici require a new firewall rule?

No. SD Elements does not connect to the Devici workspace. The OTM file is uploaded by the user from their browser to SD Elements over the same connection they already use for SD Elements. No new firewall rule is required on either side.

Are there any new services to deploy?

No. Import from Devici uses existing SD Elements services. No new ports, no new processes, no Remote Integration Agent dependency.

Is there an API for triggering imports?

Yes. The same import can be triggered programmatically via the SD Elements REST API by `POST`ing the OTM file as a multipart upload:

curl -X POST \
  "https://your-sde.example.com/api/v1/projects/{project_id}/devici-import" \
  -H "Authorization: Token $SDE_API_TOKEN" \
  -F "otm_file=@threat-model.otm"

The full request and response schema is documented in the SD Elements REST API reference.

Troubleshooting

The Devici tab does not appear on my project

Check, in order:

  1. The SD Elements release is 2026.6.1 or later. See Admin → About.

  2. The Import from Devici feature flag is enabled in Manage Features. See Enabling Import from Devici. The flag is system-wide — once enabled, the Devici tab appears on every project for every user with View Project permission.

  3. The current user has View Project permission on the project.

The Import from a Devici file option does not appear on the Get Started Modal

The Import from Devici feature flag has not been enabled. See Enabling Import from Devici. The flag must be enabled by an SD Elements administrator with the Manage Features permission before the option appears in the Get Started Modal on every project in the tenant.

The Import from Devici flag is not in the Manage Features list

The SD Elements release is older than 2026.6.1. Upgrade to 2026.6.1 or later. The flag does not exist on releases prior to GA.

The import completes but no Countermeasures are generated

If Countermeasures generated is 0 on the Import Summary, the most likely explanation is that the source Devici model has no built-in attributes set on its Elements and no custom mitigations attached to its threats. Open the Devici tab to confirm the source model has attributes on its Elements, then re-export and re-import. If the source model genuinely contains only Elements with no attributes (uncommon for a complete threat model), the import has nothing to generate Countermeasures from until the architect adds attributes in Devici.

A non-zero Custom mitigations count with a zero generation count would indicate a system error and should be reported to sdesupport@securitycompass.com.

I get the error OTM document failed validation

The uploaded file is not a valid OTM v0.2.0 document. Re-export from Devici (see Exporting an OTM from Devici); Devici exports always pass validation. If the file was produced by a third-party tool, it may need a one-time conversion.

results matching ""

    No results matching ""