Approval Security

Approval Security governs how strongly an approver has to authenticate before a sensitive or privileged action is allowed to proceed. When a PAM elevation or an AI tool action lands in the approval queue, Breeze already knows how risky it is – it carries a risk tier. This tab lets you say, for each risk tier, the minimum assurance level the approver must clear on their Breeze Authenticator device before their “Approve” actually counts.

The idea is step-up verification: a low-risk approval can be a quick tap, but signing off on a critical action should demand your strongest proof of identity. Approval Security is the policy that draws those lines.

Reach it at Settings → Organizations → (organization) → Security & Access → Approval Security. The policy set here applies across your MSP – it is the per-partner enforcement floor, not a per-device setting.

Note

Approval Security sets the assurance bar for a decision. It does not decide whether an action needs approval in the first place – that is Privileged Access Management (the rule chain, the queue, and the auto-approve / require-approval verdicts). PAM decides an action needs a human; Approval Security decides how convincingly that human must authenticate.

Risk tiers and assurance levels

Every approvable action is classified into one of four risk tiers. Breeze ships a default assurance floor for each – the minimum verification strength required out of the box:

Risk tier	Breeze default floor
Low risk	L1
Medium risk	L2
High risk	L3
Critical risk	L4

The four assurance levels describe increasingly strong proof, performed on the approver’s enrolled Authenticator device:

Level	What the approver must do
L1 – session tap	A simple tap to confirm within an authenticated session.
L2 – biometric	A biometric check (Face / fingerprint).
L3 – biometric + PIN	Biometric plus a PIN.
L4 – hardware key + re-auth	A hardware-attested, platform-bound security key – Breeze verifies the attestation server-side, not just a claim from the device – plus fresh re-authentication (password or login MFA).

Tip

The policy is raise-only. For any tier you can require a higher assurance level than the Breeze default, but you can never drop below it – the dropdown simply doesn’t offer the weaker options, and the server re-validates the same rule. An override that would weaken the floor is ignored (fail-closed).

An AI-authored script proposal’s risk tier comes from its independent reviewer and feeds into this same floor table like any other approvable action. A proposal that matched a strict security pattern additionally requires the approver to hold the Scripts permission and complete a fresh MFA check before they can approve it, regardless of the proposal’s risk tier — see AI Script Authoring & Review.

One ceremony for a run of supervised approvals

From v0.113.0, approving several supervised Tier-3 AI tool calls in a row no longer prompts a passkey or authenticator ceremony for each one. The first ceremony issues a short-lived grant — 120 seconds, bound to your identity, session and current factors, and separately audited — which the decisions that follow reuse. Four-eyes approvals are unaffected and still take a fresh ceremony every time; a grant presented on a four-eyes decision is refused and the normal ceremony runs instead.

Configuring approval assurance

1. Open Settings → Organizations → (organization) → Security & Access → Approval Security.

2. For each risk tier (Low, Medium, High, Critical), pick the minimum assurance level you want to require from the dropdown. Only levels at or above the Breeze default for that tier are selectable.

3. Optionally turn on Require an enrolled approver device to enforce the policy – under-assured approvals (including approvals from a technician who hasn’t enrolled an Authenticator device) are blocked rather than merely flagged.

4. Optionally set an Enforce from date. This is the grace-window cutoff: before that date the policy is advisory, giving your team time to enroll their devices; on and after it, enforcement is live.

5. Click Save.

Enrolling an approver device

Registering a Breeze Authenticator (approver) device always requires a fresh identity check that is independent of the login session – possession of a signed-in browser or a stolen token is never enough to enroll a new approval device.

• From the web dashboard, registering a device prompts for a step-up in order of strength: a passkey tap if you have one enrolled, otherwise your TOTP code, otherwise your password. If your account has a passkey or TOTP factor, the password fallback is refused – the server insists on the strongest factor you own (except on deployments with MFA disabled platform-wide, where the password path remains available). A newly registered device shows a “pending — activates on first approval” badge until it decides its first request.
• From the mobile app, no separate ceremony is needed: signing in (including completing your MFA challenge) authorises the app to register itself as your approver device on that login. If registration couldn’t happen at sign-in, the app shows a banner and completes it on your next login.

Each device in the list carries a badge – Hardware-attested or Not attested – showing whether Breeze has server-verified proof that its signing key lives in hardware. Only a hardware-attested device can satisfy the L4 assurance floor for critical-risk approvals; a device marked Not attested still works for lower tiers, but critical-tier approvals from it are refused, even if it was already enrolled. On mobile this usually means the app needs an update – see Approver Device Registration and Assurance for what determines the badge and how the app’s own banner explains it. A passkey / platform authenticator registered from a browser is treated as hardware-attested for this purpose, as long as it is a single-device, non-backed-up credential.

Note

Mobile app builds older than v0.99.0 used a flow the server no longer accepts, so registration from an outdated app fails until the app is updated. If a technician’s phone stops registering as an approver device after a server upgrade, update the Breeze mobile app. A device that does register on an older build still shows Not attested and stays capped below L4 until it is updated.

How it interacts with PAM and Breeze Authenticator

When an approver acts on a request from any surface (the Privileged Access console, the Helper desktop app, or the mobile app), Breeze looks up the request’s risk tier, resolves the required assurance level from this policy, and demands that level of verification on the approver’s Breeze Authenticator device before recording the decision.

• PAM elevations – UAC intercepts and Tech JIT admin requests are risk-tiered, so the assurance floor you set here is what an approver must clear to grant them.
• AI tool actions – privileged actions proposed by the Breeze AI agent or Helper carry a risk tier (for example T2 / T3) and are held for a human; the approver must meet the matching assurance level to sign off.

Because an approval always requires a separate human identity from the requester, Approval Security is what makes “confirmed with MFA” concrete: it defines exactly how strong that confirmation has to be for the risk at hand.

Caution

If Require an enrolled approver device is on and enforcement is live, a technician who has not enrolled a Breeze Authenticator device – or who can only satisfy a level below the tier’s floor – cannot approve requests at that tier. Make sure your approvers are enrolled before the Enforce from date arrives.

Related

• Privileged Access Management – the rule chain, request queue, and elevation flows whose approvals this policy governs.
• Users & Roles – roles, permissions, and MFA for the technicians who act as approvers.