Security & data
Security & data protection.
How AtēnaOs handles the data a library trusts it with: store as little as possible, expose nothing that isn't needed, record every administrative change, and fail on the safe side.
Data minimization
AtēnaOs is not a second database of your library. The catalog, patron records, and loans remain in your library system — AtēnaOs integrates with it and reads what a given operation needs, when it needs it. There is no data migration and no parallel copy of your records to keep in sync.
What AtēnaOs stores itself is limited to what it must hold to operate: item identifiers for gate authorization, device and licensing records, configuration, and operational logs. Patron data held on the platform is kept to the minimum required for the features an institution actually uses.
Patron privacy
Public self-service devices are treated as untrusted by design:
- No personal identifiers in URLs. Card numbers, patron identifiers, and e-mail addresses never appear in addresses, device history, or server logs.
- No persistent session on the kiosk. A patron's session on a public kiosk exists only on the device for the duration of use. Nothing about the patron persists on the kiosk afterwards.
- Lookups over request bodies. Patron lookups from public devices are sent in request bodies, not query strings, and are rate-limited to prevent enumeration.
Access control
Staff access is individual and bound to place:
- Per-operator accounts. Every staff member signs in with their own account and PIN — no shared logins, and actions are attributable to a person.
- Per-device binding. Each device is enrolled and credentialed individually; a staff session is tied to the device it was opened on. A device can be blocked or retired centrally at any time.
- Session controls. Resetting a PIN or deactivating an account invalidates that operator's sessions everywhere. Sessions use hardened cookies and are regenerated on sign-in.
- Brute-force lockouts. Repeated failed sign-in attempts trigger progressive lockouts, and failures are logged.
Auditability
Every administrative change on the platform — configuration edits, account and device management, licensing actions — is written to an audit log with who did what and when, including the state before and after the change. Credentials and secrets are never written to the log. The audit trail is available to platform administration and cannot be edited from the applications.
Fail-secure gates
Security gates authorize items against live loan data, scoped to the institution and branch. The default answer is no: an item that is unknown, unreadable, or not authorized raises the alarm rather than passing silently. Alarm events are recorded — what was read, at which gate, and when — and are available to staff at the desk for review and analysis.
Hosting & GDPR
AtēnaOs is hosted in the European Union and operated with GDPR obligations in mind. A data processing agreement is available on request, and we will describe our processing activities and sub-processors as part of your procurement review.
The public website you are reading now sets no cookies — the only thing it stores is your light/dark theme preference in your own browser — and it loads no third-party resources: no analytics, no trackers, no external fonts or scripts.
We do not list certifications we do not hold. If your institution has specific security or compliance questionnaires, send them to us — we answer them directly and honestly.