Phone-as-credential access control.

Frontelio Access is the physical-access-control module built into Frontelio. It treats a door, room, lift, locker, or any other secured space as a Zone. It treats permission to enter that Zone as a Grant. The credential a worker presents is a JWT minted by us: an Android phone broadcasts it over NFC, and an iPhone shows it as a QR code (in the app, or as an Apple Wallet pass) for a QR-scanning reader to read. The reader posts it to /access/verify; we check the credential's signature, the Zone, the worker's grant, and the Zone's opening hours, and respond GRANT or DENY in under 100 ms.

Because the worker and the HR record live in the same database, deactivating or terminating someone in Frontelio (an HR termination, an offboarding, or a scheduled end date taking effect) revokes their access grants automatically. Each decision is written to an audit log you can read in /admin/access → Audit. One product, one bill. That revoke applies to Frontelio-native readers; doors run by a connected Kisi, Salto, Brivo, HID Origo, or Latch system follow that platform's own rules (see Integrations).

How it works

Three steps from the worker's perspective:

Everything beyond that — Zone authoring, grant management, visitor passes, integration with existing readers — is on the admin side at /admin/access in the web console.

Concepts

Zone

A physical space that can be unlocked. A door, a stockroom, a roof access, a tip-jar locker, a delivery hatch, a fridge that needs to track who opened it for compliance. Zones belong to an Outlet (or a Tenant directly for shared spaces) and reference one or more readers by ID — the bridges that physically protect the zone. A Zone can also carry opening hours per weekday, read in your tenant's timezone; outside them, /access/verify denies. Doors imported from a connected access platform are linked to a Zone from the door side, so the events they report are tagged with it; they are not listed in the Zone's readers.

Grant

Permission to enter a Zone. Each grant ties one User to one Zone, with an optional note and an optional expiry:

• Expiry: set an end date and time and the grant stops working then (e.g. a 6-month contractor). There is no start date: a grant is valid from the moment it is created.
• Zone opening hours: whether a tap works also depends on the Zone's hours (see Zone above). Frontelio does not look at the worker's shift, so there is no shift-window or buffer around it.
• Per user, not per role: there are no role-level grants. The bulk endpoint creates one grant for every user and Zone pair in the lists you send (POST /access/grants/bulk).
• Revocation: revoking a grant takes effect on the next tap. Deactivating or terminating the user revokes all of their active grants.

Credential

A 24-hour JWT (HS256) signed by Frontelio. Minted on demand by POST /access/credential when a worker opens "My Access". The user and tenant are claims inside it; there is no per-tenant signing key. On Android the app keeps the current credential in app-private storage (not separately encrypted) so the NFC service can present it, clears it when My Access closes, and stops presenting it once it has expired; we set requireDeviceUnlock=true so a locked phone won't broadcast. On iPhone the same JWT is the QR code, in the app or inside the Apple Wallet pass. The credential identifies the user — it does not embed Zone permissions, because permissions are checked server-side at verify time. This means revoking a grant takes effect on the next tap, not when the credential expires.

API Key

A per-tenant secret (format: mk_ + 32 URL-safe characters, from 24 random bytes) that authenticates reader bridges to the /access/verify endpoint. Mint and revoke in the admin UI under /admin/access → API keys. Convention is one key per outlet so you can revoke a stolen Pi without rotating every other bridge's key.

Reader

Anything that hits /access/verify — a Frontelio reference bridge, or a partner's custom hardware that speaks the verify protocol. Each reader has a unique readerId string. Readers that belong to a connected Kisi, Salto, Brivo, HID Origo, or Latch system are not readers in this sense: they never call /access/verify, and their doors and events appear under Integrations and in Audit instead.

The Raspberry Pi bridge posts a heartbeat to /access/reader-heartbeat about every 5 minutes, and that is what puts it in /admin/access → Readers: online while its last heartbeat is under 15 minutes old. The ESP32 bridge does not send heartbeats, so it does not appear in the Readers tab; its taps show up in Audit. Custom hardware can send heartbeats by calling the same endpoint.

Visitor

A time-limited pass for someone without a Frontelio account: a contractor, an inspector, a food-delivery driver. Created in /admin/access → Visitors; redeemable via a magic link (the invite code itself is the bearer secret). Closes the Kisi/Brivo "visitor management" capability gap.

Sample data flow

Here's what a single phone tap looks like end-to-end, with timestamps:

T+0      Worker opens "My Access" in the mobile app.
T+50ms   Mobile -> POST /access/credential (Bearer <userJWT>)
T+120ms  API mints + returns { credentialId, expiresIn: "24h" }
         (credentialId is the 24-hour JWT).
T+121ms  Mobile registers the credential with the Android HCE service.

T+5s     Worker holds phone to reader.
T+5.1s   Reader emits SELECT AID (00 A4 04 00 07 F0 4D 49 53 53 41 4E 00).
T+5.15s  Phone HCE service responds with the credential JWT.
T+5.2s   Reader bridge -> POST /access/verify (Bearer mk_*)
         { credentialId, readerId: "BRIDGE-cafe1-door1", source: "PHONE_NFC" }
T+5.28s  API checks, in order: reader is bound to a Zone, Zone is active,
         credential signature + tenant OK, the user's grant is ACTIVE and
         not expired, and the Zone is open right now (tenant timezone).
         Writes the audit row, then answers { decision: "GRANT", ... }.
T+5.29s  Bridge pulses relay GPIO HIGH for 800ms (door opens).
         The audit row is already visible in /admin/access -> Audit.

When to use this

• You already run Frontelio for scheduling + checklists + payroll, and access is the missing piece. Highest ROI because everything is already connected.
• You're on Kisi or Brivo and want one audit log across your doors. The integrations layer imports the platform's doors and events, so you can start in a weekend. It does not push grants or revoke access on the platform: to get HR-tied revoke on a door, put a Frontelio reader on it.
• You're deploying a new cafe or kitchen and want phone-tap access from day one without paying $30/door to a standalone access SaaS. Deploy a $75 Raspberry Pi bridge per door (see Reader bridge).
• Compliance / audit — you need a single time- stamped trail of who entered which space, alongside their shift records, for inspection or insurance.

When NOT to use this

• High-security perimeter access (e.g. a bank vault, a server room with regulatory requirements). Phones get dropped, shared, and lost — for a vault you want a physical token + biometric. We're aimed at staff/back-of-house, not critical infrastructure.
• Sites with zero connectivity. Verify is an online call — a bridge does NOT cache credentials offline (deliberately, so revokes are immediate). If your door is in a basement with no LTE and no WiFi, this isn't the right system.
• You don't use Frontelio. The whole pitch is the shared audit log + HR-tied revoke. As a standalone access product without the rest of the platform, you're better off with a purpose-built tool.

Next steps