Built secure by design

PIM Manager governs the most powerful access in your Microsoft tenant, so it has to be held to a higher standard than the access it governs. It runs in your own Azure subscription, each part signs in with its own identity, and Invardia has no access to your installation by default.

Sign-in through Microsoft Entra ID

Your administrators sign in to PIM Manager through Microsoft Entra ID. The sign-in front needs no client secret: it proves itself with a federated credential of PIM Manager’s own managed identity. The install first sets up the built-in Azure Container Apps sign-in, which uses a client secret of the sign-in app, valid for 2 years. That secret stays on the app registration as a fallback until you remove it; once people sign in through the front, you can remove it with the steps in Remove the old sign-in secret. A session lasts 8 hours by default, and your own Conditional Access and MFA rules apply at each sign-in.

Each component has its own identity and its own rights

  • PIM Manager reads your directory with read-only Microsoft Graph permissions and stages changes. It cannot change the database structure, and it starts the engine only if you grant it that one right.
  • The engine holds the write rights in your tenant and changes only what your data defines. A few optional parts write in their own area, such as the hybrid worker in the Active Directory organizational units you name.
  • The identity that pulls software images has no database access at all.
  • In the database, each component that uses it has its own database user and its own role, and the product’s grants change only through one signed procedure. On Pro, the updater is a full database administrator so it can apply releases at night without a person; you can take those rights away. The Invardia Support app is in the database admin group only if you create it for a support case and grant it access.

No vendor access by default

Invardia has no identity, credential or network path into your tenant unless you ask for help with a troubleshooting case and create the Invardia Support app yourself. You choose its level, create its secret, decide how long it lives and remove it when the case is done. By default its secret is not renewed without your approval. Troubleshoot is read-only in Microsoft Graph and Azure; Setup adds write rights there. At either level, if you give the app access to your installation, it is a database administrator of the PIM database (db_owner) until you take that back. Its sign-ins and its changes in Entra ID and Azure appear in your own logs; statements it runs against the database are recorded if you switch on Azure SQL auditing. The steps are on Remote support access.

Changes wait for a person

  • A change you stage reaches your tenant only when someone commits it, and the stored model is backed up first. The automatic paths, such as the daily reconcile and auto-extend, follow settings you control.
  • Every PIM policy change set waits for a SuperAdmin’s approval, which covers exactly that change set. Approve all approves each waiting change set separately, each for its own exact plan.
  • One administrator can offboard a day-to-day admin. A second administrator approves first for a sensitive admin, such as one on tier 0, or for every admin when you switch on the second approver (Pro, off by default). That approval uses the Approvals page, which acts only when a SuperAdmin switches on Approval-gated offboarding + revoke, off by default; while it is off, an offboarding that needs approval cannot be saved.
  • No date, reconcile or engine pass deletes an account. Only a person’s Delete account does, and Entra ID keeps the account restorable for 30 days.

Extra caution right after an update

The day after a new engine version is when surprises happen, so PIM Manager halves every numbered safety limit for 24 hours: how many rows one commit may remove, how many accounts a run may disable, and more. Anything above the lower limit waits for a SuperAdmin. The Guards page shows when Strict mode ends, and a SuperAdmin can end it early with a reason.

A record you can check

PIM Manager and the engine write an audit trail with before and after values, append-only for their own identities. Switch on Azure SQL auditing to your own Log Analytics workspace to also record statements by the database administrators, outside the database.

Updates you can trust

  • Each Pro update is signed, checked against a key built into the product, and built from source inside your own registry.
  • A version reaches customer installations only after a person at Invardia has approved it, and that approval is recorded with a reason.
  • A failed health check rolls the update back, a release that asks for a manual step is held, and the updater does not move your installation to an older version by itself.
  • You can hold your installation at its version, change the schedule, or switch off Pro updates and update by hand.

Help from the people who build it

Pro support comes from the people who build PIM Manager. Every ticket has a number, one owner at Invardia and a priority, and is updated by mail and in the customer portal until it is solved.

Mail you can act on at a glance

Each message names the environment it is about and, when it matters, says whether something failed, needs attention, or needs you to act. For example: [Production] Action needed: 4 role requests waiting for approval [PIM Manager]. Mail rules and shared mailboxes sort them without effort.

Your license, only yours

Your license is a signed file bound to your tenant. When it is time to renew, PIM Manager proves it holds the current license before Invardia sends a new one, so only an installation holding the current license and its install key can ask for the renewal.

Read the details

← PIM Manager · Architecture and security (technical) → · Security review pack →