Architecture and security

Entra Policy Suite gives every user and device the tags your Conditional Access policies and dynamic groups depend on, from rules you control. It watches those tags for changes it did not make and reports your identity gaps every day. It runs in your own Azure subscription and keeps its data in your own database. This page covers Entra Policy Suite 2 Community: how the parts fit together, how they sign in, who can do what, and how long data is kept.

At a glance

• Runs in your own tenant and subscription. The jobs, the web app, the database, the container registry, the job queues and the Key Vault are installed into one resource group of your subscription. Nothing is hosted by Invardia.
• Your data stays in your environment. Rules, runs, tag changes, identity report snapshots, tamper events and the audit trail are kept in your own Azure SQL database. The Community edition sends nothing to Invardia.
• Writes tags, and one Conditional Access change on approval. The engine writes the extension attributes of your tag types on users and devices - in Entra ID through Microsoft Graph, and for AD-synced users in Active Directory through the hybrid worker. It changes a Conditional Access policy only when a SuperAdmin moves an adopted policy to another stage, after seeing what changes; nothing else creates, changes or deletes a policy.
• Preview first. Every tagging run builds a plan before it writes. A feature is off after the install, and the tagging mode is Preview until you choose Apply.
• Managed identities only. Every part signs in with its own managed identity. There is no client secret and no certificate to create, store or rotate.
• No PowerShell modules. The install, the jobs and the hybrid worker use REST and .NET only.
• Governed changes. Rule changes wait in a commit queue until an admin commits them, and every change is in an append-only audit trail.

Components

Component	What it does
Scheduler	A Container Apps job that runs every 5 minutes, works out which job is due, and asks for it by putting a message on that job’s queue
Work jobs	Container Apps jobs, each started from its own queue: user tagging, device tagging, identity report, tamper monitor, the CA Policy Analyzer (the read of the Conditional Access policies) and configuration (the job that applies the changes people make in the web app)
Web app	A Container App with Microsoft Entra sign-in: rules, commit queue, tag types, condition types, identity report, tamper events, Conditional Access, jobs, runs, tag changes, settings, access and audit
Hybrid worker	A scheduled task on a domain-joined Windows Server (Azure VM or Azure Arc-enabled server): writes the tags of AD-synced users in Active Directory and reads AD users and groups
Azure SQL Database	Every rule, setting, run, tag change, snapshot and audit row. Microsoft Entra authentication only.
Storage account	One queue per job, through which the scheduler asks for runs. Shared keys are off.
Container registry	The Entra Policy Suite image, built inside your registry from the release
Key Vault	One key that protects the web app’s sign-in sessions, plus - when Invardia has issued one - the connection key for Invardia’s support uplink, which only the engine can read
Log Analytics	The container logs

Identities and secrets

Identity	Rights	Why
Engine (managed identity)	Microsoft Graph application Policy.ReadWrite.ConditionalAccess (the stage move); User.ReadWrite.All / Device.ReadWrite.All only while a feature that writes users / devices is on (removed otherwise); read only User.Read.All, Device.Read.All, GroupMember.Read.All, Organization.Read.All, AuditLog.Read.All, Policy.Read.All, RoleManagement.Read.Directory, DeviceManagementManagedDevices.Read.All, Application.Read.All; Exchange Online Exchange.ManageAsApp with the Exchange Recipient Administrator role; send as the alert mailbox only	Writes the tags; reads what the rules, the identity report, the tamper monitor and the Conditional Access page need; sends the alerts
Engine, in the Key Vault	Key Vault Secrets User on the uplink connection key only	Reads the connection key Invardia issued for the support uplink, and no other value in the vault
Engine, on the web app	Reader on the web app’s container app only	Reports to Invardia which version of the sign-in front the web app runs. It can change nothing in Azure.
Scheduler (managed identity)	Message sender on the job queues	Asks for runs. It holds no Microsoft Graph right and cannot start a job itself.
Web app (managed identity)	Its own database role; the Key Vault key of the sign-in	Reads the database and records requests. It holds no Microsoft Graph, Exchange or Azure management right.
Hybrid worker	The server’s managed identity (database, worker role only); a group managed service account delegated to the tag attributes in the OUs you name (Active Directory)	Takes its own work and writes the AD tags. It cannot read or change rules or settings.

• An approver who does not approve a read permission can leave it out at install; the feature that needs it reports its data as unavailable.
• The engine may send mail as one shared mailbox only (Exchange role-based access for applications). It holds no tenant-wide right to send mail.
• There is no client secret or certificate for any identity.

Network

• The web app has a public HTTPS endpoint behind Microsoft Entra sign-in. Only people assigned to its enterprise application can sign in, and your Conditional Access policies apply to that sign-in.
• The jobs reach Microsoft Graph, Exchange Online and the database over HTTPS from the Container Apps environment.
• The hybrid worker connects out to the database. Nothing connects in to it, and it needs no public IP address.
• The install and the launcher reach Microsoft Entra ID, Azure Resource Manager, Microsoft Graph, the database and GitHub (for the release).

Sign-in and access layers

1. Microsoft Entra ID. People sign in with their Entra account to the web app’s own app registration (single tenant, assignment required, no secret).
2. Roles in Entra Policy Suite. Reader, Admin or SuperAdmin. Someone who is not named is a Reader. A role is bound to the person’s account, so a new account with the same UPN does not inherit it. The last SuperAdmin cannot be removed.
3. The engine. A change made in the web app is recorded with the person and their reason, and the engine carries it out after it checks the person’s role at that moment. The web app’s own identity cannot change the directory or the configuration.
4. The database. Each part has its own database role with object-level grants on the tables it uses. No part is owner, reader or writer of everything.

Change control

• Rule, tag type, tag value and condition type changes are checked, then staged in a commit queue. An admin commits them; a change to something edited in the meantime fails. A second approver can be required.
• Every tagging run plans before it writes. Preview records the plan only; Apply writes it. Runs can be limited to a saved test scope.
• A run whose plan is far larger than usual is held for an admin’s approval.
• Every setting, schedule and access change needs a reason. The protection settings need a SuperAdmin.
• The audit trail records every change and every refused request with who, when, why, before and after. The database refuses to change or delete an audit row.
• Every rule, tag type, setting and scope keeps its version history, and an earlier version can be put back as a new change.

Licensing and integrity

• Entra Policy Suite Community is free. It needs no license key.
• Releases are published on GitHub. The launcher checks the download against the SHA-256 digest GitHub publishes for it before it unpacks it.
• The container image is built inside your own registry from the release.

Invardia’s touch points

Invardia has no access to your tenant or subscription. An installation sends Invardia nothing unless Invardia has issued it a key, kept in the installation’s own Key Vault: then the uplink job sends a heartbeat every 4 hours and one record per finished run - numbers and states only, never a user, device, tag value or object name - and a SuperAdmin can switch it off in Settings. The Support app for Invardia is in both editions and is off until you create it in your tenant for a case; you remove it when it is done. Pro: support from Invardia (the support service, the Support app and just-in-time database access - each optional). Community: help on GitHub; the Support app is optional.

Data retention

Data	Kept
Rules, tag types, values, condition types, settings, scopes and their version history	Until you change or delete them; the history stays
Runs, tag changes and run logs	In your database
Identity report snapshots	The newest 7 by default (a setting)
Tamper events	In your database, with the decision made on each
Audit trail	Append-only, in your database

Deleting the resource group removes all of it. The tags already written stay on your users and devices.

Compliance support

Entra Policy Suite helps you evidence identity controls that frameworks such as NIS2, ISO 27001 and DORA ask for: identities classified by role, privileged accounts identified and held to phishing-resistant MFA, inactive and orphaned accounts found, changes reviewed before they apply, and an append-only record of who changed what and why.