SecurityInsight documentation · Verified against SecurityInsight 3.0.79 on Nov 9, 2026

Naming

SecurityInsight follows one naming convention, shared by every Invardia product: a short code in Azure, the full name where people read. The product code is si. Names never carry the environment or the update ring; the resource group and its tags say which environment an install is.

Azure resources and identities

The purpose words are the same in every product: engine, web, updater, mcp.

Where people read

Existing installs

Azure cannot rename a container app, a job, a managed identity, a SQL server, a Key Vault or a registry. So:

• Resources keep their names on an install made before this convention. A new install gets the new names.
• Display names are renamed by the update on every install: the engine application first, then the sign-in application, and the SQL admin group’s display name - only from SecurityInsight’s earlier name; a name you chose is kept. Each is renamed once, read back, and put back if it does not take. Where the update may not rename them, an administrator runs Set-SIDisplayNames.ps1. The mail sender’s display name has always been SecurityInsight.
• Never renamed: the mail sender’s address and the Exchange scope that limits sending to it, because your own mail rules may refer to them.
• An install is never half-renamed. When an install’s resource group already holds any component under the earlier names, every component keeps the earlier names, also when setup is run again.

SecurityInsight never finds its own resources by a name written into its code. Every install records the names it runs with, and every part of SecurityInsight reads them from that record, so earlier and new names work side by side.

Verified against SecurityInsight 3.0.79 on Nov 9, 2026Download PDF

← Support accessSettings →