Service desk
Incidents, catalog, service levels, and approvals sit on the same identity graph as the door. An anomaly hold can raise a ticket, and so can a revocation that needs human confirmation.
Built from the other direction.
Most service desks began as ticket systems and added an asset database later. The order of construction shows.
Baselivery started from a session authority, which had no choice but to know who holds which laptop, which team owns which shared workstation, and who approved a piece of equipment leaving the building. The service desk inherits all of that on the day it is switched on.
So the parts that are usually a consulting workstream are simply present. Assets on a ticket come from the register rather than a text field. Approvers come from the directory groups that already govern physical access. The custodian of a device is not a guess.
Ticket semantics stay conventional on purpose. Priority derives from urgency and impact, service levels count down and breach visibly, catalog items carry their own intake forms. The control plane emits into those workflows; it does not rewrite them.
- Ticket types
- Incident, request, change
- Priority
- Derived from urgency and impact
- Service levels
- Response and resolution targets with breach visibility
- Catalog
- Items with typed intake forms
- Approvals
- Shared with the gate-pass chain
- Portal
- Self-service reporting and requests
- Assets
- Linked from the register, not typed in
- Dependency
- None on the control plane
Where security events become work.
The interesting integration is not a webhook. It is that the ticket already knows the person, the device, and the zone.
A portal raises a hold
A tailgate hold or a presentation-attack signal creates a ticket with the portal, the claimed principal, and the session already attached. Nobody has to reconstruct what happened from timestamps.
A revocation needs confirming
Where a device is off the estate and cannot be locked immediately, the revocation opens a ticket that stays open until somebody confirms the hardware is accounted for.
A request touches the register
A hardware requisition moves through its approval chain and, on fulfilment, writes a deployment event against the asset. The register updates because the work happened, not because somebody remembered.
The trail is one trail
Ticket history, asset events, and access decisions share an audit surface, so an auditor asking about one incident does not need three exports.
What a ticket suite cannot do on Monday morning.
This is not a claim to be a better ticket system. It is a claim about what sits underneath one.
| Capability | Baselivery | Ticket-first suites |
|---|---|---|
| Badge and laptop as one session | A single Presence Session with shared epochs | Separate access control, device management, and helpdesk |
| Revocation across both planes | Under 500 ms on site | A ticket, then a human, then a wait |
| Asset on a ticket | Linked from the authoritative register | Often a free-text field or a stale import |
| Approvals for physical exit | Native, and readable by the policy engine | An email chain outside the system |
| Custodian of a device | Known, and enforced at the lock screen | Recorded, if the import ran |
| Access decision history | Same audit surface as tickets | A different product, if any |
Operational detail.
Self-service
End users report and request through a portal, without agent chrome.
Service levels
Due stamps on the queue and visible breach state.
Catalog
Request types carry their own forms, so intake is complete first time.
Notifications
A watch state on an admitted session can alert the security team through the desk.
Groups
Assignment groups are the directory groups you already maintain.
No lock-in
The desk works with no portals and no agents deployed.
Related
Bring the door onto the same epoch as the laptop.
We will walk you through a live portal, a compiled policy pack, and a revocation that closes the turnstile and locks the screen while you watch.