This page explains UEC’s policy model from authored intent to the binary an endpoint applies. The model exists to make policy safe at fleet scale: reusable intent, immutable approved versions, explicit assignment, and target-specific artifacts.

---

The three layers

1. Authored policy

The authored layer stores reusable intent: policy metadata, typed file/signer/path rules, and policy options. It does not store a target-specific runtime identity.

Important properties:

• supplemental authored state does not persist a base-policy binding;
• rules are typed, not arbitrary XML blobs;
• the browser never generates policy artifacts;
• multiple variants can coexist under one policy.

2. Resolved deployment intent

Before artifact generation, UEC resolves what a particular target should receive:

Input	Result
Device’s BaseDeviceGroupId	The one base feed
Supplemental group memberships	Contributing additive trust
Effective mode metadata	Audit, enforce or disabled
Base context	Which base supplemental artifacts merge against

This is why a supplemental policy can be reusable: its binding is computed for the target rather than frozen into the authored row.

3. Final artifact

The final layer owns Windows-required identifiers and target output:

• base version emits Audit and Enforce artifacts with the same stable control identifier;
• supplemental policy emits a merged artifact per supplemental group and base context;
• identifiers such as PolicyID, BasePolicyID and VersionEx are generated here;
• agents receive artifacts through the artifact feed, not a legacy per-policy XML path.

---

Variant lifecycle

Draft → Review → Approved → Deprecated → Archived

Transition	Meaning	Guard
Draft → Review	Submit for inspection	Validation must pass
Review → Approved	Make eligible for assignment	Approval permission required
Approved → Deprecated	Flag replacement	Existing assignment continues
Deprecated → Archived	Remove from catalog	Version must be unassigned
Pre-approved → Archived	Discard unused work	Allowed when unassigned

The canonical review action is Approve. UEC does not expose “Publish” or “Promote” as synonyms because those words hide which lifecycle transition occurred.

---

Assignment lifecycle

1. Approve a variant.
2. Assign it to the correct group type:
   • base policy → base device group;
   • supplemental policy → supplemental group.
3. Choose audit for a new or changed trust envelope.
4. Wait for agents to download and report the artifact.
5. Review execution telemetry.
6. Promote to enforce for the smallest safe ring.
7. Expand ring by ring.

---

Modes

Mode	Behaviour	Use
Audit	Policy evaluates and reports would-be decisions without blocking	New policy, changed trust, new ring
Enforce	Agent blocks behavior outside policy	After soak and operational sign-off
Disabled	Reset/remove policy from the device	Exceptional recovery, not routine administration

Device-level mode divergence is an override, not a normal assignment. It requires expiry, has a tenant-configured maximum duration and leaves durable audit history.

---

Rules and trust anchors

UEC prioritizes high-finity anchors over brittle ones:

1. Publisher / signer TBS hash — allow a publisher’s cryptographic identity where possible.
2. File path / PFN — useful when path stability is part of the control.
3. Authenticode hash — precise but must be updated whenever the binary changes.

Do not use application names or version strings as trust anchors. They are useful for humans and classification, not cryptographic proof.

---

Policy options owned by the base

A base policy owns platform behavior:

• HVCI / kernel integrity;
• Windows Update protection;
• managed installer;
• Intelligent Security Graph;
• script enforcement;
• whether supplemental policies may augment the base.

A supplemental policy cannot override these switches. This prevents two supplemental groups from inconsistently changing platform-wide guarantees.

---

Safe ring pattern

Ring	Devices	Mode	Exit criteria
Ring 0	1–5 IT-owned devices	Audit	No boot, driver, security-agent or core business failures
Ring 1	One department or pilot group	Audit	Business applications verified; false blocks converted to rules
Ring 2	Pilot group	Enforce	24–72 hours stable; response owner on call
Ring 3	Business unit	Audit → Enforce	Change window and rollback owner
Broad fleet	Remaining groups	Enforce	Support process ready

Keep a rollback owner and a rollback artifact before enforcement. A base policy failure can prevent software from running; that is more serious than a dashboard showing red.

---

Convergence and drift

Policy convergence has multiple stages:

1. Assignment saved.
2. Artifact generated.
3. Agent notified or sync hint received.
4. Agent downloaded the correct artifact.
5. Agent applied it.
6. Heartbeat reported applied policy identity/mode.
7. Events show the expected audit/enforce behavior.

Do not stop checking after step 3. Use Devices, Policy Deployments, Events and the device detail page to confirm the end-to-end state.

---

Audit and immutability

Approval, assignment, mode changes, overrides, deprecation and archival are audit-worthy events. Approved rules are immutable; change happens through a new variant. This gives a stable review record and a precise rollback target.

See Audit Log for actor, resource and field-level diff review.