PIM Manager -- Security review pack

1. Architecture

PIM Manager keeps privileged access in Microsoft Entra ID and Azure in line with a desired state that your administrators manage. It runs entirely in your own Azure subscription, in a resource group you choose (default name rg-pim). Invardia does not host the product, your data or its runtime.

Components (all in your subscription)

• Engine job ca-pim-tick -- an Azure Container Apps job on a schedule. It reads the desired state from SQL and applies it to Entra ID, PIM for Groups, Azure RBAC, Intune and Defender XDR role management through REST calls with its managed identity.
• Manager ca-pim-manager -- the web GUI (Container App). Administrators sign in with Entra ID through the product's sign-in front (OpenID Connect code flow with PKCE, no client secret); the Manager itself listens only on the container's loopback address, behind it. Its Microsoft Graph rights are read-only; changes are queued in SQL and applied by the engine.
• Updater job ca-pim-update -- builds the new version from source inside your own container registry and rolls the Manager and jobs (chapter 6).
• Azure SQL Database -- the desired state, settings, audit log and commit journal. Entra-only authentication. The installer creates it on the Standard tier, S0 at minimum (never Basic, never serverless), with a 250 GB maximum size; a higher tier you set is kept, and a pim-sql-tier-pin tag stops the product changing its tier.
• Azure Container Registry -- holds the images built in your subscription (Premium for private network setups, Basic otherwise).
• Log Analytics workspace -- receives the Container Apps logs.
• Key Vault -- only when a feature needs a secret (SMTP relay password, emergency passphrase, MSP signing key). A plain install creates none.
• Optional: PIM Activator browser extension with its own app registration (chapter 2), the access-request (RFA) broker ca-pim-rfa, an MCP endpoint on the Manager, and a hybrid worker VM for on-premises Active Directory.
• MSP installs add a managing-tenant side (a signed baseline bundle published to storage, pulled by each managed tenant).

What Invardia hosts

• invardia.com: the download of standalone setup scripts, licences, the optional update channel for Pro, and the receiver for the telemetry uplink (chapter 4). None of these is needed for the product to keep running; the engine runs without any call to Invardia.
• Invardia never hosts your directory data, your SQL database or your runtime.

Network exposure options

• Default: the Container Apps environment is external. A new Manager is created closed (a deny-all ingress rule) and is opened only after Entra sign-in is configured and verified. Worker jobs have no ingress at all.
• IP-restricted: ingress IP allow-rules can be added; the update path keeps them.
• Private: an internal-only Container Apps environment and a SQL private endpoint with public network access disabled are supported install options (opt-in).
• SQL: Entra-only authentication. Setup sets the SQL server's minimum TLS version to 1.2. A public install uses the Azure rule "Allow Azure services"; private networking (a VNet rule or a private endpoint) is a setup option.

Data flow summary

• Engine and Manager -> Microsoft Graph / Azure Resource Manager / Defender / Power BI / Exchange Online REST: HTTPS, managed identity tokens.
• Engine and Manager -> Azure SQL: TLS (Encrypt=True, certificate validated), managed identity.
• Administrators' browsers -> Manager: HTTPS, Entra sign-in.
• Product -> invardia.com: HTTPS, outbound only (telemetry, licence, optional updates). Nothing from Invardia connects in to your environment.

2. Identities

Every identity the product creates or uses, with its purpose and lifetime. Runtime identities are managed identities -- no secret or certificate to steal or rotate. The default resource names are shown; an installation may prefix them.

3. Permissions with justification

Every permission the product grants or requires, per identity, read from the install and grant code of this version. Optional means the grant is made only when you choose that feature or switch. The engine needs broad write rights because managing privileged access is its job; chapter 8 explains the controls around that.

> The engine identity's Graph permissions are tier-0 equivalent: RoleManagement.ReadWrite.Directory can assign any directory role and AppRoleAssignment.ReadWrite.All can grant any application permission. The engine identity is monitored as a tier-0 asset, and the most privileged directory roles (Global Administrator, Privileged Role Administrator) are refused as engine targets.

Least-privilege choices made in code

• The Manager's Graph rights are read-only; writes are queued and applied by the engine.
• Mail.Send is never granted tenant-wide to the engine or Manager; mail uses Exchange RBAC for Applications scoped to ONE mailbox, and the mail setup removes a tenant-wide Mail.Send if it finds one.
• Exchange Administrator for mail setup is activated time-bound through PIM (default 4 hours), not assigned permanently.
• User Access Administrator at the tenant root is opt-in; the default is Reader.
• Workload identities may only be given Reader, User Access Administrator or Role Based Access Control Administrator by the reachability planner; Owner and Contributor are refused there.
• The baseline-publish job has no fixed SQL role: SELECT on named objects only, and db_owner / db_datawriter / db_ddladmin / db_datareader are revoked.
• Storage keys are disabled where the product creates storage; access is Azure RBAC.
• One identity per job in SQL: every component that uses the database has its own contained database user, mapped from its own managed identity. The image-pull identity has no database access, and the web app holds no db_ddladmin (from 2.4.631): it cannot change the schema.
• SQL admin group = the database job identity only: its standing member is the database job identity (id-pim-dbinit); people get in just-in-time through PIM for Groups. No runtime identity of the web app or the engine is a member, the updater is never a member, and a new installation does not make the Invardia Support app a member (chapter 5).
• One custom database role per component (pim_web, pim_engine, pim_updater, pim_asbuilt, pim_publish, pim_downlink, pim_hybrid), object- or schema-level, never db_owner. Grants change after a release ONLY through one certificate-signed procedure (pim.usp_ApplyAccess) under fixed rules: a pim_ role, SELECT / INSERT / UPDATE / DELETE / EXECUTE, PIMs own schemas, never itself, never a fixed role. Its certificate lives in the database, expires 2099-12-31 and has no private key (removed after signing); altering the procedure drops the signature. The updater may only EXECUTE it and is refused when it grants directly; the engine cannot run it (proven on a live installation). Every update applies schema and grants with the updaters own database user alone, so the SQL admin group may stay empty for years.
• The web app cannot change the engine: start-only rights on the named engine job (Jobs Operator), no registry push, no SQL admin.

Least privilege by component

• Access reviews use AccessReview.ReadWrite.All, the narrowest Graph permission that creates and completes reviews.
• Every component holds only its own custom database role (pim_web, pim_engine, pim_updater, pim_asbuilt, pim_publish, pim_downlink, pim_hybrid); per-component views separate the generic settings and rows tables. Rights change only through the certificate-signed access procedure.
• The updater holds Contributor on its own resource group only, and is a contained database user with schema rights only; it is never in the SQL admin group. In Microsoft Graph it holds three PIM-for-Groups permissions, GroupMember.Read.All and Application.Read.All (both read only) and Application.ReadWrite.OwnedBy (changes only the app registrations it owns), and nothing else (owner decisions 2026-11-05 and 2026-11-07): it makes the database job identity an active member of the SQL admin group -- a role-assignable group, through PIM for Groups, permanent where the group policy allows -- reads that membership back before the database job or the support job starts, and renews a time-limited membership before it ends. It holds no directory role; the permissions are tenant-wide in Microsoft Graph, and the updater's code uses them on the SQL admin group only.
• The optional deploy app registration holds its rights only for the length of an install.
• The standalone Grant-PimEnginePermissions script grants only the roles and scopes on the product's allow-list.

4. Data

Data read from your tenant

• Users (names, UPN, mail, enabled state, last sign-in time), groups, owners and members, Entra roles and PIM schedules and policies, administrative units, domains, subscribed SKUs, applications and service principals, access reviews.
• Azure management groups, subscriptions, role definitions, role assignments and PIM-for-Azure schedules (Azure Resource Graph).
• Intune and Defender XDR role definitions and assignments; Power BI workspaces (when those workloads are managed).
• Authentication methods of the admin accounts it manages (to issue a Temporary Access Pass).
• On-premises AD users and groups (hybrid worker only).
• Not read: sign-in logs, audit logs, risky users, Conditional Access policies, mailbox content, files.

Data stored (your Azure SQL database, in your subscription)

• Desired state and definitions (admins, groups, roles, departments, workloads) -- includes admin names, UPNs and manager e-mail addresses.
• Settings, a tenant cache of what was read, the managed-object ledger (what the engine owns).
• The change queue and approvals.
• Audit log (pim.AuditEvents: who, what, before, after) and commit journal (pim.CommitJournal: before/after of every commit, initiator, approver) -- both append-only by trigger.
• Configuration backups and pre-commit snapshots.
• MSP managing tenants: a registry of managed tenants (app ids and certificate thumbprints only, secrets as Key Vault pointers).
• Not stored: TAP codes and generated passwords (shown once, never written). API keys are stored as SHA-256 hashes only. The SMTP password and emergency passphrase are in Key Vault, not SQL.

Retention

• AuditRetentionMonths -- default 0 = keep forever; when set, 13 to 1200 months (1-12 refused); a daily job purges and the purge itself is audited.
• Configuration backups -- ConfigBackupRetentionDays default 90 (1-3650); pinned and newest kept.
• Pre-commit snapshots -- 10 per entity. Job run history -- 10 per job.
• Commit journal, applied-commit log and change queue -- purged with the audit retention; the purge itself is audited.
• Log Analytics keeps the workspace default retention (30 days) unless you change it.

Data sent to Invardia

All outbound, HTTPS, to invardia.com. Nothing is sent about users, groups or roles by design; the exact fields are below.

• Telemetry uplink (run reports hourly, a heartbeat every 4 hours; feature gate telemetry.uplink, on by default, switch off in Settings > Features; switching off sends one final opt-out record and then nothing). Two modes: anonymous (no licence install key: a random install id, bucketed counts, no tenant, host or text) and identified (with an install key: adds tenant id, host name and redacted error text). The redaction removes tokens, keys, SAS signatures and PEM blocks; it also removes e-mail addresses, UPNs and object names from error text. The identified heartbeat also carries the environment name your administrators gave the installation (the name shown in the Manager header) and the guard mode (normal, or strict with its end time).
• Licence request (every 30 minutes until a licence is installed; gate licence.autoRequest, on by default): product, version, tenant id, install id, current licence id and expiry. No contact details. When a licence is installed, the request also proves it: it sends the SHA-256 of the installed licence file and, with an install key, the key in a request header, so only the installation that holds the licence can ask for its renewal.
• Install-key claim and update manifest (gate updates.invardia): Pro sends product, tenant id, licence, ring; Community asks the public release channel for its ring and sends nothing else.
• Install tracking (only when an install is started from an Invardia install token): the step names and outcomes.
• Licence validation itself is offline: a signature check with no network call.

Encryption and residency

• At rest: Azure SQL Transparent Data Encryption with service-managed keys, or customer-managed keys as an option. Key Vault for secrets.
• In transit: HTTPS to every API; SQL connections with Encrypt=True and certificate validation. Setup sets the SQL server's minimum TLS version to 1.2.
• Residency: every resource is created in your subscription in the region you choose. The installer's region list is West Europe, Sweden Central and Denmark East. Invardia receives only the uplink fields above.

Deletion on uninstall

See chapter 10. Your SQL database (and so all stored data) remains until you delete the resource group or the database.

5. Access by the vendor

Invardia has no access to a PIM Manager environment unless you create the Invardia Support app in your tenant. You decide whether it exists, at which level, and for how long. When you name it to the installation, it gets one standing right on the PIM database: a read-only user (next section). Admin rights on the database exist only for an open support session of at most 8 hours, at setup level.

Database access (when a Support app is named)

• What: the Support app has its own database user in the PIM database, in the read role pim_support_read (read access to the product's own tables, nothing else). The user is created from the application's client id; no directory lookup is involved. It is not a member of the SQL admin group (grp-pim-sql-admins) and not a database owner.
• Support sessions (setup level only): admin rights on the database (db_owner) are given to the same user only for an open support session -- at most 8 hours after it opened -- and are taken back when it ends. Every session is recorded. At troubleshoot level no session gives admin rights.
• What it reaches: the one PIM database -- the desired state, settings, audit log and run history described in chapter 4, read only outside a support session. It does not reach other databases, and it is not a right in Entra ID or Azure.
• When it is given: by the installation, at every support level, when you name a Support app (Grant-PimSupportAccess.ps1). With no Support app named, nothing is created.
• How it is checked: the end-of-install check has a line for it. It says "in place" only when it read a database user with the Support app's id in pim_support_read from the database; the same user also in db_owner is a warning, never "in place"; otherwise it says it could not be checked, or that it is not in place, with the next step.
• How you end it: switch the Support app off or delete it in Entra ID (the access ends at once, because the database user can no longer get a token), or run Grant-PimSupportAccess.ps1 -Remove (drops the database user).
• Installations made before this: an earlier version gave the Support app a standing db_owner and a membership of the SQL admin group. A new run of Grant-PimSupportAccess.ps1 does not add them again and says when they are still there; -Remove takes them back.
• What this means for you: whoever holds the Support app's secret can read the PIM database for as long as the app is enabled, and change it only during an open support session. The secret is held as described under Credential and conditions below; every action is in your Entra sign-in log and in PIM Manager's own audit log.

What the Support app can do

The app's tenant rights are created by Invardia's own setup script (published at invardia.com/support), not by PIM Manager. In that script:

• Troubleshoot level: read-only Graph (directory, applications, users, groups, roles, PIM policies and schedules, PIM for Groups read) plus Application.ReadWrite.OwnedBy (to renew its own secret); Azure Reader and Log Analytics Reader on the resource groups you name; Key Vault Reader.
• Setup level: adds Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, DelegatedPermissionGrant.ReadWrite.All, Group.Create and RoleManagement.ReadWrite.Directory in Graph, and Contributor + User Access Administrator on the subscriptions you name (optionally at the tenant root), Key Vault Secrets Officer, Network Contributor on a hub VNet. Setup level is tier-0 equivalent -- grant it for an install or repair, then lower it.
• PIM Manager's own grant script (Grant-PimSupportAccess.ps1) gives, at every level, the read-only database user described above -- and nothing in Entra ID: no group membership, no ownership of the product's app registrations or groups.
• As-built document (level `asbuilt`, also part of troubleshoot and setup): the Support app may start the one as-built job (caj-pim-asbuilt) and read its executions, and may read the one storage container asbuilt -- nothing else. The job writes a PDF describing the installation's configuration (no secrets, people, user names or object ids) to that container. The storage account accepts only Entra tokens (no shared key, no anonymous access), so the PDF is readable only by the Support app's identity after you grant it, and it is deleted after 24 hours. Your admins download the same PDF from PIM Manager without any of this.

Security changes to an existing installation

• Infrastructure changes to an installation that is already running (for example tightening database rights, turning on SQL auditing or shortening the sign-in session) are never made by the updater. They are made by Invardia through the Support app, one environment at a time, with a script that shows a plan first, reads every change back and writes a rollback record. Every SQL statement goes through Invardia's support SQL route, which records the statement and its reason before it runs.
• Order: Invardia's own environment first, then the test environments, then each customer environment in batches, with a check of the engine runs between batches. Customers are told beforehand.

Credential and conditions

• The Support app uses a client secret (this is the only identity in the product allowed one, and only for setup and support, never for the runtime). For customers it expires after 90 days; old secrets are removed when a new one is made. Invardia keeps it in its support Key Vault.
• Invardia's sign-in tool checks that the token's tenant and app match the environment, refuses a production environment without an explicit production switch, and stops when you have disabled the environment.
• An optional Conditional Access policy can restrict the app to Invardia's support IP address; it is created on wherever the tenant has Workload Identities Premium.

How you remove it

1. Grant-PimSupportAccess.ps1 -Remove -- takes back the SQL user, a membership of the SQL admin group or ownerships an earlier version gave, and the as-built job and container access.
2. Invardia's New-InvardiaSupportApp.ps1 -Action Disable (sign-in blocked, grants kept) or -Action Remove (deletes the app, its Azure roles and the Conditional Access policy).
3. Or simply delete the app registration / service principal in Entra ID.

Audit trail

• What the Support app does is visible in your Entra sign-in and audit logs and the Azure Activity Log.
• PIM Manager's own audit log records every action the Support app makes against Graph, Azure or SQL, and the Review active assignments page shows the Support app's own assignments.

6. Supply chain

How code reaches your environment

• Every update builds the product from source inside your own container registry and rolls the Manager and jobs. No pre-built vendor image is pulled. The updater job ca-pim-update does this on its schedule; an installation that turns it off updates by command (below).
• The signed Invardia update channel: the update manifest is signed (RS256, RSA 4096) and verified against a public key embedded in the product -- never fetched at run time. The manifest must name your ring, a version, a SHA-256, a size and a sequence number (replays are refused); the download must be HTTPS; the archive's SHA-256 and size are checked before unpacking, and the version inside must match the manifest.
• Source-archive channel (self-hosted updates): the archive is fetched from a storage container the update job is configured with, then built in your registry, rolled and health-checked like any other update.
• No storage token in the updater: Pro installations fetch the source archive from invardia.com for the version their signed manifest names; the update job no longer keeps a storage SAS URL in its settings. The container registry's admin user is off.
• Updating by command: Update-PimCommunity.ps1 -Apply reads the same signed release and checks it the same way, downloads the archive, checks its SHA-256 and size, and deploys it with the parameters your last deploy saved. Without -Apply it shows the version it would move to and the deploy plan. The deploy upgrades the database first, runs a health check and rolls PIM Manager back when the check fails.
• Licences: signed (RSA-SHA256) and verified offline against embedded public certificates, both before storing and after reading back.

Rings, who releases, and your control

• Rings 0-3: 0 development, 1 test, 2 design partners, 3 broad. Ring 2 is never advanced automatically.
• A release is built only from a tagged source version and published by a dedicated publisher identity. Each release carries a fingerprint of the engine code and says whether the engine changed since the previous release.
• Release control: Invardia refuses a ring 2 or ring 3 release, or an early wave, of a version the release owner has not marked APPROVED (with a reason, audited, append-only). A wave serves a version to named installations inside a ring only after that version was released to a lower ring; stopping a wave never moves an installation back. After a release that changed engine code, installations report more often for the first hours, and each release collects evidence (guard trips, the engine's own changes, run results) for the owner's decision. Rings 0 and 1 are never held. A publish whose answer is lost (a server error) is read back before anything is retried, so a release is never published twice.
• Strict guards after an engine change: for 24 hours after an update that changed engine code, every numbered safety limit is halved (chapter 7).
• Invardia holds the update-signing key. Your controls: the update hold freezes the environment at its version; downgrades are refused; a minimum-from version prevents skipping a required step; updates run on a schedule you can change (default 03:00 UTC daily); the update job can be removed for fully manual updates.

Source availability

• The source is published in a public GitHub repository (linked from invardia.com), so the code you run can be read and compared with what is built. The Community edition is licensed under the PolyForm Shield License 1.0.0 (free to use and change, not to build a competing product); Pro is delivered in the Pro package under a commercial licence and is not in the public repository.

Dependency policy

• No PowerShell modules at runtime: the engine, Manager, updater and the published setup scripts use REST and .NET only, with browser sign-in.
• The container base images are pinned by digest; the container runs as a non-root user.
• The one NuGet package (Microsoft.Data.SqlClient) is pinned by version and by hash.
• Exceptions, outside the runtime: the hybrid worker for on-premises AD uses the Windows ActiveDirectory and GroupPolicy modules (RSAT) on its worker VM (an Azure VM the setup builds, domain-joined, in its own VNet peered to your domain controllers); some local-only operator modes of the Manager can use Microsoft Graph / Az modules when already installed.

7. Change control and audit

Every change is staged, then committed

• Changes made in the Manager are staged and only reach the tenant when committed. The engine applies only what is defined in the database: an object the product does not own is reported, never removed (the managed-object ledger). An unreadable ledger prunes nothing.
• Commit journal: every commit records before and after, who initiated it and who approved it, in the same transaction as the change -- if the journal row fails, the change fails. Append-only by trigger.
• Undo: a commit can be undone by planning its inverse and committing it through the same gates (SuperAdmin: any commit; Admin: their own).
• Backup and restore: a snapshot before every apply; configuration backups on a schedule; an environment backup can be imported with a plan first and the engine paused, never overwriting what exists.

Approvals

• Second approver (off by default): on Pending changes, a SuperAdmin can require that a different administrator commits each sensitive change, or every change. Pro adds maker/checker (off by default): when it is on, changes classified as sensitive (privileged roles, Tier 0/1, guests, offboarding) need a second administrator to approve them, and the maker cannot approve their own request unless a SuperAdmin switches on Allow an administrator to approve their own requests (off by default). Community has no maker/checker.
• Always on: changing the break-glass list needs a second SuperAdmin, with no self-approve switch.

Guards (always on)

• Never disable accounts when the desired admin set is empty or could not be read; account disable is opt-in.
• Limits are counts. No guard uses a share of a list or of the scanned accounts. Three guards have a limit that a SuperAdmin sets on the Guards page, inside a fixed range: the commit removal check (default 25 rows of one list in one commit; range 5 to 200), the removal budget (default 5 removals per scope per run; range 1 to 25) and the mass-disable breaker (default 3 accounts per run; range 1 to 25). The removal budget is one number for every way the engine removes: removals in a list, a prune, a reconcile, offboarding, group deletion, a queued group delete and a retraction on a managed tenant. A stored value outside its range, or one that cannot be read, is ignored and the default applies. An environment setting can lower a limit and can never raise it. No guard can be switched off.
• Commit removal check: a commit that takes more rows than the limit out of one list, or keeps none of the rows the list has now (also when new rows are added in the same commit), or would leave 2 rows or fewer of a list that has more than 5 rows, is not saved until a SuperAdmin approves exactly those rows in the commit dialog, with a reason. The server decides who may approve; an Admin cannot.
• Removal budget per scope: a run that would remove more than the limit removes nothing in that scope and holds the list. A SuperAdmin approves the exact list when it is committed (the run then applies exactly those items, each once, whatever their number), or releases a list a run already holds. Deleting groups goes through the same approval. Anything that is not in the approved list is still held; an approval ends by itself after 48 hours.
• Mass-disable breaker: a run that would disable more accounts than the limit disables none and holds the list; a SuperAdmin releases exactly that list of accounts for one run.
• An approval or a release is given only by a SuperAdmin of the tenant signed in to the Manager, is bound to the exact list (a changed list is held again), needs a reason and is audited (who, when, why and every item). A release lasts one run or at most 24 hours. Approvals, releases, held lists and limits are never restored from a configuration backup and never copied by an environment import or a settings copy, so a used or revoked approval cannot come back; a record whose own times do not add up (no start time, a start in the future, an end later than its lifetime allows) counts as ended. The break-glass exclusion, account deletion by a prune or reconcile, shared workload assignments, objects the product does not own and the last Manager SuperAdmin are locked: they have no limit and can never be approved, exempted or released.
• Account deletion -- one operator-controlled path. The product never deletes an account it does not manage, and a prune or reconcile never deletes anything: an undefined account is only reported. The only delete is an operator's Delete account on a PIM-managed admin account (a SuperAdmin, an Admin, or a delegated operator for admins at or below its level, typing DELETE; that confirmation is the approval). The engine then deletes it once -- sessions revoked first, never a break-glass account, never an enabled account the disable circuit breaker did not allow, at most 5 per run, and never on a managed tenant on the managing tenant's word (there it is disabled). Entra keeps a deleted user restorable for 30 days. Turn the path off per environment with PIM_ADMIN_ACCOUNT_DELETE=0.
• Strict mode after an engine change. For 24 hours after an update that changed engine code, every numbered limit is halved from the value the SuperAdmin configured: effective = max(1, floor(configured / 2)), so a limit of 1 stays 1. It covers the commit removal check, the removal budget, the mass-disable breaker, bulk revoke, account deletion, the policy brake counts and the hybrid server batch. The Guards page shows configured and effective limits and when Strict ends; the header shows "Guard mode: Strict" to SuperAdmins. A SuperAdmin can end Strict early with a reason, which is audited. A strict trip is held like any other trip. On the first version that brings Strict to an installation, it only records the engine fingerprint, so the switch itself never starts it.
• Every guard trip is mailed, audited and reported. Every mail subject names the environment and, when it matters, a severity word: [<Environment>] Failed | Warning | Action needed: <what happened> [<ticket>] [PIM Manager], at most 120 characters.
• Break-glass accounts in Settings are never removed, disabled or revoked; if the list cannot be read, every account is treated as protected.
• The engine has a dry-run (-WhatIf) mode; scheduled jobs can be paused one by one or all at once.

Manager roles

• None, Reader, Delegated, Admin, SuperAdmin. Hosted with no authenticated principal = no access (401). The access model refuses to be left without a SuperAdmin.

Audit

• pim.AuditEvents records actor, source, action, target, before, after and dry-run flag; append-only by trigger; purged only by the retention job (minimum 13 months; default keep forever).
• Logs of the Container Apps go to the Log Analytics workspace in your subscription.
• SQL auditing is on: the SQL server sends its security audit events to the installation's own Log Analytics workspace, kept 90 days, so every statement by any identity -- including the Invardia Support app -- can be reviewed there.
• Only the updater holds a schema right; any schema change and any direct SQL write is recorded by the SQL audit in your workspace, outside the database.

8. Threat model and hardening

The top risks for a privileged-access product and the controls that answer each one. Every control below is part of the design: it is built into the product, applied by setup and kept in place by every update, so no customer has to configure it. The checklist after it lists what you can add in your own tenant.

9. Compliance mapping

How PIM Manager's controls can support your own controls. This is not a certification and does not make your organisation compliant; you remain responsible for your controls and their evidence.

10. Uninstall and exit

Removing the product

• Fastest complete removal of the Azure side: delete the resource group the product was installed in. That removes the Container Apps, jobs, SQL server and database (all stored data), registry, Log Analytics workspace, Key Vault (soft-deleted for 90 days, then purged) and user-assigned identities.
• Remove-PimContainerStack.ps1 removes only the container apps, jobs and Container Apps environment and their role assignments at subscription scope, and deliberately keeps SQL, registry, Key Vault, storage, network and identities -- use it to rebuild, not to exit.

What remains after deleting the resource group (remove by hand)

• Role assignments made at the tenant root management group or on other subscriptions (Reader, optional User Access Administrator).
• App registrations: the Manager sign-in app, the access-request app, the engine and deploy app registrations (when created), the PIM Activator app.
• Groups: grp-pim-sql-admins, the Manager users group, the Power BI admin-API group.
• The mail sender's shared mailbox and its Exchange management scope and role assignment.
• The Invardia Support app (chapter 5).
• Everything the engine created in your tenant on purpose: admin accounts, PIM groups, administrative units, role eligibilities and assignments, PIM policies. These are your access model -- they keep working without the product. Remove or keep them as part of your exit plan; the Manager's reports and the managed-object ledger list them before you uninstall.
• On-premises: hybrid worker gMSAs, AD delegations and the server GPO.

Exit

• Export your configuration (Settings > backups) before removal; it is JSON you keep.
• One uninstall script removes the installation and lists what remains for you to remove by hand.

11. Scripts

Scripts are run by highly privileged people, so they are listed here one by one with the rights needed and the changes made. Every published script is: listed in SHA256SUMS.txt; a shown command of two lines, download then run, with SHA256SUMS.txt published for whoever verifies (never pipe-to-execute); no second-stage downloads (one stated exception, the installation launcher, below); -WhatIf preview; a transcript; browser sign-in, no secrets in or out.

How to run a script

PIM Manager shows every script command as two lines -- line 1 downloads the file from Invardia, line 2 runs it (more run lines only when a flow needs them); the documentation page is the link next to the command:

1. Download it: Invoke-WebRequest https://invardia.com/support/pim/<Script>.ps1 -OutFile <Script>.ps1
2. Run it, with -WhatIf (or -PlanOnly where the table says so) first: .\<Script>.ps1 -WhatIf

Optional, for whoever verifies before running (never part of the shown command): compare Get-FileHash .\<Script>.ps1 -Algorithm SHA256 with the line in SHA256SUMS.txt published next to it, and Read it -- each script is one self-contained file; the source is also in the public repository.

Facts that hold for every published script

• Listed in SHA256SUMS.txt, published next to the scripts.
• No PowerShell modules; REST and .NET only; browser sign-in (no device code).
• No pipe-to-execute anywhere in the product; scripts do not download and run further code -- with one stated exception: Start-PimManagerInstall.ps1, whose job is to download the public PIM Manager release from GitHub into a new folder, compare its SHA-256 with the one the release publishes (when it publishes one), and run the installer of that release.
• A transcript of every run is written; some scripts also write a result file with -OutFile.
• Every script has its documentation page and an entry in the documentation manifest (framework 12.7).

Published scripts and their checksums

Every PIM Manager script Invardia publishes at invardia.com/support/pim/, with its documentation page (what it does, the rights it needs, every change it makes, -WhatIf and undo) and the SHA-256 of the exact published file, computed when this page was built.

Always check the SHA-256 before you run a script.

Download, read, run

Never pipe a script into Invoke-Expression. Download it to a file (line 1), read it, preview with -WhatIf (line 2), then run the same line without -WhatIf:

Invoke-WebRequest https://invardia.com/support/pim/<Script>.ps1 -OutFile <Script>.ps1
.\<Script>.ps1 -WhatIf

To check a download, compare its SHA-256 (Get-FileHash) with the publishedSHA256SUMS.txt or the table above.

Each script's page shows these commands with its own name. All scripts: PIM Manager scripts · Every setting explained: PIM Manager settings