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 at the reader is a JWT minted by us and broadcast from the worker's phone over NFC (Android) or shown as a QR code (iOS). The reader hits /access/verify, we check signature + Zone + shift window + revoke list, and respond GRANT or DENY in under 100 ms.

Because the worker, the role, the shift schedule, and the HR record all live in the same database, terminating someone in the HR module cascades to their access grants the same minute. Same audit log as payroll and checklists. One product, one bill, one trail.

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 — those are the bridges or integration-mapped doors that physically protect the zone.

Grant

Permission to enter a Zone. Each grant ties a User to a Zone, optionally with constraints:

• Time-bounded: only valid between a start and end date (e.g. a 6-month contractor).
• Shift-aware:only valid during the worker's active shift window for that outlet (the most common cafe use case — staff get in 15 min before their shift, locked out 30 min after).
• Role-cascaded: a Role-level grant flows down to every User holding that role, so HR-terminating someone automatically pulls the access.

Credential

A 24-hour JWT signed by Frontelio with the tenant's signing key. Minted on demand by POST /access/credential when a worker opens "My Access". Never stored unencrypted on the phone; on Android we set requireDeviceUnlock=trueso a locked phone won't broadcast. 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 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, a third-party reader via the integrations layer (Kisi, Salto, Brivo, HID Origo), or a partner's custom hardware that speaks the verify protocol. Each reader has a unique readerId string. Readers heartbeat every 5 min to /access/reader-heartbeat so the admin UI shows them online/offline.

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 credentialJwt (24h TTL).
T+121ms  Mobile registers credential with 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 credentialJwt.
T+5.2s   Reader bridge -> POST /access/verify (Bearer mk_*)
         { credentialId, readerId: "BRIDGE-cafe1-door1", source: "PHONE_NFC" }
T+5.28s  API validates: signature OK + grant exists + shift active
         + reader is in Zone + not in revoke list. -> { decision: "GRANT" }
T+5.29s  Bridge pulses relay GPIO HIGH for 800ms (door opens).
T+5.30s  Audit row written. Visible in /admin/access -> Audit immediately.

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 frustrated with the per-door pricing, the separate audit log, or the lack of HR-tied revoke. Switch in a weekend with the integrations layer.
• 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