Fleet owner's console
Issues contractors organization certificates with scopes: device groups, roles, privilege and duration ceilings.
Tessera Access · certificate login
Offline certificate login with managed delegation
Personal, accountable login for engineers and contractors on any device running Astra Linux or other Linux — from operator workstations and ATMs to POS terminals and industrial controllers. All rights live inside the certificate; all validation happens on the device itself. No network is needed at login time at all.
Offline
the device itself verifies the certificate, expiry, revocation and scopes — without a network
Identity
every login is tied to a specific engineer — including contractor logins
In production
already running in production across bank ATM fleets
Astra Linux SE: MIC, closed software environment
GOST crypto · Rutoken / JaCarta
PAM module with an open core
Windows — on the roadmap
01 · How it works
Five steps — from policy to revocation
-
Issuance
The administrator defines which roles an engineer may log in under and on which device or group of devices. The certificate authority (CA) issues a short-lived certificate with those rights inside — onto a USB stick under a PIN.
-
Login
The engineer plugs in the USB stick, enters the PIN and picks a role. The PAM module on the device performs the certificate authentication itself and opens the session — without a single network request.
-
Session
The session opens at exactly the requested role — least privilege (the smallest set of rights that works), 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. The system watches the medium continuously: no token, no session.
-
Revocation
The administrator revokes access via the revocation list (CRL) — including ending live sessions or locking the device out entirely. Even if the list never reaches the device, the certificate expires on its own: hours or a shift, not months.
Five questions the device answers on its own
- Is the pass genuine? — signed by the certificate authority
- Issued for this very device? — the binding is written into the certificate
- Still valid? — not expired and not revoked
- Does the role allow the requested level?
- Does the holder actually own the key? — the device demands a signature, not just showing the certificate
not a single network request
02 · Delegation
Delegation: every link can only narrow the rights
The fleet owner issues the service organization a certificate with hard scopes. The organization issues its engineer an even narrower shift certificate. Stepping outside the scopes is impossible.
Fleet owner
A bank, an industrial company, a critical-infrastructure operator. The root of trust — only the owner decides who may do what.
rights: entire fleetOrganization certificate
- devices: region "North" only
- roles: "maintenance" only
- issued credentials: ≤ 30 days
rights narrowed to the contractor's scope
Service organization
The contractor. Issues credentials to its own engineers — but only inside the scopes it was given.
rights: region · 1 roleEngineer's shift certificate
- device: ATM-0042 only
- role: "maintenance"
- valid for: 8 hours
rights narrowed to a single shift
Engineer
Arrives on site with a certificate on a USB stick or token. Needs no network.
rights: 1 device · 8 hLogin to the device
- the device verifies the whole certificate chain itself, offline
- the session opens at exactly the requested level — never more
least privilege at login
Device
Any device running Linux / Astra Linux. Verifies signatures, scopes, expiry and revocation — without a single network call.
offline validationThe guarantee lives on the device itself. Even if a contractor's issuing CA is compromised, it cannot produce a working certificate outside its scopes: a southern ATM rejects a "northern" contractor's certificate on its own, offline, based on its own signed data.
03 · Certificate issuance
Issue your own certificates — in a minute, from your own console
No manual cryptography and no external certificate authority: the dispatcher issues a certificate in a web console, and the system keeps it inside the scopes.
Service organization's console
The dispatcher issues shift certificates to their engineers per work order — the form cannot step outside the organization's scopes.
Straight onto the medium
Written to a USB stick or token (Rutoken / JaCarta) at the dispatcher's desk; short lifetime means a lost medium simply expires.
The engineer carries updates
Next to the certificate the console places a fresh revocation list, configuration and updates — the device applies them at login on its own, after verifying the signature.
Every issuance is journaled
Who issued what, to whom, for which device and with which rights — and who delivered which update. CLI and API planned for ticket-system integrations.
04 · Mechanisms
Every claim is a mechanism, not a promise
Cryptography
X.509, PKCS#11 and PAM
Login through the native Linux PAM stack. Hardware tokens (Rutoken or JaCarta with GOST algorithms) — or a PIN-protected container on any USB stick. Standard formats, no vendor lock-in.
Device
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.
Time
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.
Rights
Roles and enforcement (applying the rights)
The role in the credential becomes real constraints: Astra mandatory integrity controls, groups, sudoers, systemd limits. Not “access in general” — exactly the level needed.
Revocation
CRL and revocation
Revocation is forever: a monotonic crlNumber prevents replaying an older list. Live sessions get revoked; the device goes into quarantine.
Audit
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.
Scale
Delegated issuance
Intermediate certificate authorities (CAs) for branches and contractors get delegation boundaries (name constraints) that the device verifies offline. A delegate cannot step outside them.
Compliance
GOST and certification
GOST cryptography with certified modules (CryptoPro CSP, Rutoken) for FSTEC-regulated environments. First target platform — Astra Linux SE.
Network
Hybrid fleets
When there's a connection to the server, a sync agent pulls roles and revocation lists — it only downloads, never sends anything out. Poor network only affects how current the roles and revocation lists are — never the security model.
05 · Management & resilience
Managed from one place, lives without it
Fleets of tens of thousands of devices: delivery via signed files over any channel, login never waits for the network.
Centralized management
Roles, policies, revocation (CRL) and inventory for the whole fleet — in one Tessera Control; administrator ≠ auditor. You can also start with no server at all: roles and keys go into the device image.
Tessera Control · standalone works too
Astra Linux as a native platform
Privilege level = mandatory integrity level: the session opens with the exact label, checked bitwise. Signed components, works with the closed software environment enabled, login through the native fly-dm screen.
SE, MIC, closed software environment
Audit on the device
Every login, logout and denial is an event in a hash-chained journal: tampering and deletion are visible. Uploaded to Control when connectivity exists; export via the engineer’s medium for air-gapped sites.
tamper-evident · works offline
Simple to install and keep current
Installation is a package plus configuration files; a built-in readiness self-check (doctor). The agent core is open source: your security team can see exactly what runs on the devices.
no DB · no daemons on the login path
A component failure is not a hole
Server unreachable? Login with valid certificates keeps working; expired ones don't get renewed. When in doubt, it refuses entry (fail-closed) — by design. Security is identical with or without the server — the server is there to manage the fleet and keep data current, not to make login secure.
Codes unavailableone-time code server
we loseissuing new QR codes
keeps workingcert login · enforcement · audit · TTL revocation — everything else
Control unavailablefleet control plane
we loseup-to-date CRL and roles · commands · fleet-wide overview
keeps workinglogin · enforcement · journal to a local buffer (at-least-once) · TTL backstop
Offline for monthszero-egress fleet
we loseonline delivery (rollout or courier remain)
keeps workingeverything — this is the normal mode, not an emergency
Attack on the channelsync delivery
we loseat most — a delivery DoS
keeps workingtransport is untrusted: signatures + anti-rollback; falls back to the offline model, not a weakened one
Failure of a server component does not open the door — and does not lock out a valid engineer. There is no fail-open here.
06 · Scenarios
Where this is needed today
ATMs · zero-egress
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.
View configuration example
Defense industry · CNC
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.
Critical infrastructure · GOST
Regulated environments
Role accounts 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
Issuancewho approved, checks
Credentialcode or certificate
Sessionopen · actions · close
Terminationtrigger
Device journal — hash chain
seq nhash(prev)
seq n+1hash(prev)
cut outchain breaks
seq n+3hash(prev)
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
07 · FAQ
Frequently asked questions
Can we issue our own certificates for workstation login?
Yes, that's the primary scenario: the fleet owner and contractors issue certificates in their own consoles, and keys stay in a PKCS#11 token or HSM. No external certificate authority is needed, and every issuance is journaled.
How does certificate login on a workstation work?
The engineer plugs in the medium, enters the PIN and picks a role. The PAM module on the workstation itself verifies the signature, expiry, revocation and device binding — and opens the session with exactly the role's rights. No network is needed at login.
Do we need a domain or a controller?
No. All validation happens on the device itself: no domain controller, no bastion, no network access. Air-gapped fleets are the normal mode.
Which systems are supported?
Linux with PAM: the first target platform is Astra Linux SE (MIC, closed software environment), and it works on other distributions too. A Windows adapter is on the roadmap.
Next step — a pilot on your fleet
A few devices, your maintenance scenarios, your contractors — and a before/after audit comparison.
or email us: tessera@tessera-access.com