See every Microsoft 365 policy as a CI. Catch conflicts before users do.

No. The integration only requests read-only access. Kovira cannot create, edit, or delete policies. If a policy needs to change, you change it in Microsoft 365 and the next sync reflects it.

Sync runs every 24 hours per integration. The first sync after connecting runs immediately so the data is visible within minutes. The cadence matches typical Microsoft 365 admin workflows where policies change infrequently and are reviewed before going live.

Kovira honours throttling instructions immediately and waits exactly as long as Microsoft asks before retrying. We never compound throttling with parallel retries, never give up on the run, and never skip a policy because of a throttle. The architecture is designed so that Kovira itself never originates a throttle response.

All the documented top-level conditions, grant controls, and session controls are captured as discrete settings, including risk levels, client app types, platforms, locations, applications, users, groups, roles, sign-in frequency, persistent browser mode, and integration with Defender for Cloud Apps. If you need deeper decomposition of a particular field, tell us and we will scope it.

Kovira tracks the last-modified timestamp Microsoft provides on every policy. The user identity behind the upstream change lives in Microsoft's own audit log; we link to it rather than duplicate it. Within Kovira, the sync history records every sync that touched the policy.

Group and user assignments are recorded for accounts present in the Entra ID directory we sync. External accounts that have not been added to your Entra directory are skipped during assignment resolution and reconcile automatically once they appear.

Kovira uses Microsoft's standard application authentication for unattended integrations, so the sync runs on its 24-hour cadence without needing any user to be signed in. Initial consent must come from a Global Administrator because Conditional Access and Intune permissions require that level.

When a Conditional Access or Intune policy targets a dynamic group, the group itself is part of the Entra ID directory Kovira already syncs. The assignment links the policy to the group regardless of how membership is determined; the dynamic membership rule lives on the group record.

No. The integration does not require any Microsoft 365 SKU above what you already need to use Conditional Access (Entra ID P1) or Intune. There is no per-policy or per-call cost from Microsoft for the read APIs the integration uses.

Yes. When a sync detects that a previously synced policy is gone from Microsoft, Kovira marks it as upstream-deleted rather than removing the record. Settings and assignments are preserved so historical conflict analysis stays usable. If the policy reappears later, the marker is cleared.

Each setting on each policy is captured as its own queryable record. The Conflicts page surfaces every setting that resolves to different values across policies whose assigned groups overlap, so the same audience does not silently get conflicting instructions. Findings are exact: no probabilistic matching, no machine learning, no false positives from treating different audiences as the same audience.

Yes. Every individual setting instance is decomposed into a queryable value with its stable Microsoft definition identifier, serialised value type, category, and display name when Microsoft supplies one. Definition identifiers remain visible when no friendly label is present, so audit and conflict matching never depend on guessed names.

The documented top-level fields are decomposed into individual settings. Deeply nested authentication strengths and custom-control payloads are preserved on the policy record so nothing is lost, and we can decompose specific nested fields on request once we know which ones matter to your audit.

No configuration is required on the Microsoft side. Kovira runs comfortably below Microsoft's published per-app rate ceilings, throttles itself before Microsoft has to ask, and limits cross-customer concurrency so a busy hour for one workspace cannot affect another. If you ever see a sync run record showing an unusual throttling event, that is operational data we surface to you, not a problem you need to fix.