Trust at the edge · trust lives in the credential
Fleet access that works offline
An engineer logs in with a cryptographic credential. Identity, role and the binding to a specific device are baked into the certificate itself — the device validates the certificate locally, with no call home at login time.
Network · server
- Tessera Control · Tessera Codes
- policy · issuance · audit
Device · offline
- certificate: identity + rights
- login + validation — on the spot
No network — yet login, validation and accountability remain. The server adds scale and freshness. Not security.
01 · Problem
Thousands of devices. A shared account — or N×M personal ones.
ATMs, CNC machines, substations — a fleet of thousands of devices with no reliable connectivity. Engineers need access that is accountable and works offline.
Option A
One shared account everywhere
A single password for the whole fleet. Zero accountability: the log shows a shared account, not a specific engineer. Revoking one engineer means rotating the password on thousands of devices.
Option B
Personal accounts on every device
N engineers × M devices. Every hire, departure and rotation becomes a fleet-wide update. On an offline fleet this is unmanageable by construction.
The third way — Tessera
One technical account + identity in the credential
The device keeps a single account. Who logged in, under which role and for how long is written into the credential itself. Full accountability without N×M.
What about classic PAM? Vault, Teleport and PASM-class bastions require the control plane to be reachable at login time: no connectivity — no access (or a workaround hole). On a zero-egress fleet they don't work by design.
02 · How it works
Five steps — from policy to revocation
-
Issuance
An administrator sets the policy: roles, devices by tag, validity period. The CA issues a short-lived certificate with the rights inside — onto a USB key protected by a PIN.
-
Login
The engineer plugs in the key and picks a role. Engine locally verifies the signature, host binding (the certificate is issued for this exact device), validity period and permitted roles — without a single network request.
-
Session
The session opens at exactly the requested role — least privilege, even if the certificate allows more. The engineer's identity is fixed in the credential.
-
The token stays in control
Pull the key out — the session ends. udev monitoring watches the medium: no token, no session.
-
Revocation
CRL, live-session revocation, device quarantine. The offline backstop: the certificate expires on its own TTL — hours or a shift, not months.
Tessera Engine — validates locally
- CA signature — chain to the root
- host binding — the certificate is for this device
- TTL not expired · not in CRL
- roles cover the level (⊇ oper)
- PoP — holds the key, not a copy
five checks · zero network requests
03 · Mechanisms
Every claim is a mechanism, not a promise
X.509 + PKCS#11
Hardware tokens (Rutoken or JaCarta with GOST algorithms) — or a PIN-protected container on any USB stick. Standard formats, no vendor lock-in.
Host binding
The credential is bound to one specific device. A stolen USB key is useless on the ATM next door — Engine rejects it locally.
Short-lived credentials
TTL of hours or a shift. Even with no link to the center, access expires on its own: time works for the defender, not against them.
Roles and enforcement
The role in the credential becomes real constraints: Astra mandatory integrity controls, groups, sudoers, systemd limits. Not “access in general” — exactly the level needed.
CRL and revocation
Revocation is forever: a monotonic crlNumber prevents replaying an older list. Live sessions get revoked; the device goes into quarantine.
Tamper-evident audit
The on-device journal is a hash chain: every record is stitched to the previous one, so tampering shows. For air-gapped sites — export by courier media.
Delegated issuance
Intermediate CAs for branches and contractors — inside name constraints the device verifies offline. A delegate cannot step outside its boundaries.
GOST and certification
GOST cryptography with certified modules (CryptoPro CSP, Rutoken) for FSTEC-regulated environments. First target platform — Astra Linux SE.
Hybrid fleets
When connectivity exists, a sync agent pulls roles and CRLs (pull-only). Network degradation changes data freshness — never the security model.
04 · Scenarios
Where this is needed today
A fleet with no outbound connections at all
USB key → pick a role → log in with no network. Revocation on the server side is instant; on the offline fleet — by TTL, hours to a shift.
An isolated shop floor
The shift operator signs in under the oper role, the service
technician under serv — each with a personal credential, rights
set by the role. A tamper-evident journal lives on the device itself;
the regulator gets a USB export.
Access under a work order
The contractor scans a QR code with a phone, the dispatcher approves online (four-eyes), and access lasts only for the duration of the work. The device itself never touches the network.
-
The ATM shows a QR offline
device_id · nonce · requested level
-
The engineer's phone: scan network
SSO / 2FA
-
Tessera Codes: checks — AND, fail-closed network
work order (ITSM) · shift window · four-eyes · device status · rate-limit → code = MAC(per-device key)
-
The code on the phone screen network
one-time, bound to the device and the level
-
The engineer types the code on the device offline
Engine verifies the MAC locally → opens the session
Regulated environments
One technical account on the device, login with a GOST token.
issuance_id ties issuance → login → actions → termination
into a single provable thread.
End-to-end correlation by issuance_id
Device journal — hash chain
tampering is detected — the broken chain shows
Anchors → Control
- anchor reconciliation (device_id, seq, hash)
- mismatch → security alert
- silence beyond the norm → gap alert
- air-gapped: the journal travels on courier media; anchors reconcile the same way
05 · Comparison
Tessera vs classic PAM and bastions
The difference is not a feature list — it's the architecture: where the access decision lives.
| Criterion | Classic PAM / bastions | Tessera |
|---|---|---|
| Offline fleet | Require the control plane to be reachable at login | Works with no network; the server is an accelerator, not a precondition |
| Network degradation | A trade-off: fail-open (a hole) or fail-closed (an outage) | Fail-closed by design + TTL backstop: valid access keeps working |
| Zero-egress ATMs | Not applicable | The target segment |
| Short-lived access | A server-side policy — the server must be there to enforce it | TTL inside the credential — expires on its own, no server involved |
| Delegation | RBAC on the server | Name constraints in the certificate — boundaries verified offline |
| Load on the center | Every login is a request to the center | Issuance and sporadic CRLs only |
06 · Resilience
A component failure is not a hole
Server unreachable? Login with valid certificates keeps working; expired ones don't get renewed. Fail-closed by design. Security is identical with or without the server — the server adds scale and data freshness, not security.
Failure of a server component does not open the door — and does not lock out a valid engineer. There is no fail-open here.
07 · Open core
Open core, commercial management
Open AGPL-3.0
- Tessera Engine — validation + enforcement
- Tessera Login — PAM module
- Certificate login
- Basic roles: groups, sudoers
- Hash-chain audit on the device
Commercial enterprise
- Tessera Control — fleet management, CRL, inventory
- Tessera Codes — one-time QR codes
- Astra mandatory-integrity adapter
- SELinux adapter
- Central audit intake + SIEM export
- GOST FFI
- Windows adapter roadmap
The principle: formats and verification are open — the device's verification code can be audited independently. Issuance, delivery and fleet management are commercial.
Let's discuss a pilot
We'll show offline login on your scenario: ATMs, a shop floor, substations. Tell us about your fleet — we'll come back with specifics on the mechanism.
or email us: tessera@robonet.me