Granting and revoking access

One of Broker's core design goals is to make access changes something an operator can do in a single click — not a change request that sits in an IT queue. This article covers how granting and revoking work in practice.

Granting access

From the Manager console, granting access is a point-and-click action: select the requesting identity (a user or a device), select the destination service, and confirm. Because every identity on the platform is certificate-based, there's no shared secret to distribute — the grant simply tells the Authorizer plane that this specific certificate is now permitted to reach this specific destination. The connection typically becomes usable within moments of the grant being recorded.

This is also distributed by design. Central IT doesn't have to be the bottleneck for every grant — an appropriately-scoped administrator (for example, a plant manager who owns a specific set of OT services) can grant access to their own resources directly, without escalating a ticket. Broader organizational policy still governs who is allowed to grant what, but the mechanics of the grant itself don't require a centralized approval workflow for every single request.

Revoking access

Revocation works the same way, in reverse: select the active grant in the Manager console and revoke it. Because the platform is certificate-based and fail-closed, revocation doesn't rely on the client honoring a "please disconnect" request — the Authorizer plane simply stops treating the identity as authorized, and the Receiver plane will not terminate a new session for it. Revocation propagates in seconds, which matters most in incident-response scenarios: if a device is compromised or an employee's access needs to be pulled immediately, you are not waiting on a VPN concentrator to expire a session or a firewall change window.

What revocation does — and doesn't — affect

Revoking a grant removes that specific path. It does not, by itself, delete the underlying certificate identity (see Certificate errors and how to fix them for the distinction between a revoked grant and a revoked certificate). If you need to fully retire an identity — for example, an employee has left, or a device has been decommissioned — you'll want to revoke both the grant and the underlying certificate so the identity can't be re-granted access later without re-issuance.

Auditability

Every grant and revocation is recorded with who performed the action, what identity and destination were involved, when it happened, and why (where a reason is provided). This is the same audit trail referenced in Understanding the admin console — nothing about access state changes silently.