Help Center/Elevation rules

Elevation rules

Rules decide what happens before anyone is asked. One rule says everything about a binary: how to recognize it, what action to take, which devices it covers, when it applies and who signed off.

How matching works

Match fields combine with AND: a rule matches when every field you filled in compares true against the incoming request. Empty fields are ignored. Every rule must carry at least one strong identity anchor: a certificate thumbprint, a SHA-256 hash, a certificate subject CN (publisher) or a certificate Organization. Path-only or filename-only rules are rejected because they are trivially spoofable: anyone can drop a matching file at the right path.

Match fields

FieldNotes
cert_thumbprintPins one signing certificate. Anchor.
exe_hashSHA-256, exact match only (wildcarding a digest is meaningless). Anchor, but breaks on every app update.
cert_subject_cnPublisher CN ("Mozilla Corporation"). Anchor.
cert_subject_oSubject Organization: catches a vendor's whole catalog across per-product CNs. Anchor.
cert_subject_ou / cert_subject_c / cert_issuer_cnNarrowing filters only; too broad to anchor a rule alone (a CA or a country signs many unrelated vendors).
product_name / original_filename / internal_name / file_description / copyrightVersion-resource fields.
path_patternInstall location filter.
file_version / file_size_bytesComparisons with operators (=, >=, and so on).

Every string field supports a per-field match type: exact, glob (wildcards) or regex.

Actions

ActionEffect
Auto-elevateSilent approval; the user never sees a prompt.
Require MFAElevates only after the user passes an MFA challenge.
Notify onlyLets the request proceed to review but fires an audit event and webhook: an observe-then-lock step for new binaries.
DenyHard block, with a required reason shown to the user.

USB rules (Allow USB / Block USB) and execution rules (Allow execution / Deny execution) use the same engine with their own identity families; see USB control and Allowlisting. The rule form keeps the three domains strictly separate: a USB rule cannot carry software identity and vice versa.

Targeting and precedence

A rule can target any mix of: the whole tenant, organizations, device groups, or individual devices. Evaluation order:

  1. Deny wins. If any deny rule matches, the request is blocked regardless of everything else.
  2. Narrower target wins among allow-family rules: device beats group beats organization beats tenant.
  3. Lower priority number wins within the same tier (default 100).
  4. On a full tie, the most recently created rule wins, so a newly authored rule overrides a legacy one without renumbering.

Schedules

A rule can be limited to a weekly window: days, a start and end time, and a timezone. All three parts are required together (a half-specified schedule silently never matching would be worse than an error). Overnight windows such as 22:00 to 06:00 work as expected.

Governance

Rule reachRequired
Client-wideExpiry date.
Tenant-wideExpiry date, review date, change ticket and a second approver.

Identity anchors are immutable after creation: to change what a rule matches, deactivate it and author a new one, leaving two clean audit events. Behavior fields (action, schedule, priority, expiry) stay editable.

Signature-gate bypass

bypass_signature_check lets a matching UNSIGNED or UNKNOWN_CA binary elevate anyway: the escape hatch for internal line-of-business tools that will never be re-signed. Guardrails: the rule must anchor on a hash or certificate thumbprint (a filename-only bypass would let any dropped setup.exe inherit it), and it cannot be combined with a deny action.

Other switches

FieldMeaning
osPlatform scope: windows, macos or any. Agents skip rules that are not for their platform.
require_mfaOrthogonal to the action: even an auto-elevate rule can still demand MFA.
execution_modeadmin, user or system for the elevated launch; empty inherits the default.
cache_ttl_minutesHow long the agent may honor the decision locally without re-asking (max 30).
apply_to_existingRetroactive apply: back-scans the last 90 days of requests and marks the ones this rule would now match, clearly labeled as after-the-fact attribution.
Building a rule from reality beats authoring from scratch: approve a request with "create rule" checked, use the file-inspect drop zone in the rule form, or promote an observed binary from execution events. All three pre-fill verified identity.