Security overview

This page describes how the ACS platform protects the access records it holds, in the order a security reviewer usually asks about them: who can get in, what they can see, what is recorded, and how the data is protected in transit and on the device. Where a control is not yet in place, it is listed as such rather than omitted.

1. Authentication

Control	How it works
Single sign-on	Sign-in is delegated to a Keycloak identity provider. The platform never handles a user's password.
Token validation	Every API request carries a signed access token. Issuer, audience, signature and expiry are all validated, so a token minted for another audience or an expired token is refused.
Session lifetime	Short-lived access tokens with rotating refresh tokens, so a leaked access token is of limited value and a stolen refresh token stops working once the legitimate user next signs in.
Device identity	Gate devices authenticate as devices and are registered to a client account before they may upload. An unregistered device is refused and retried rather than silently discarded.
Multi-factor authentication	Available in the identity provider and can be switched on per realm; not enforced by default. If you need it enforced for your administrators, ask us to enable it.

2. Authorisation and separation between customers

• Roles, not flags. Authorisation is expressed as named policies (administrator, client administrator, client user, dashboard viewer, device, database upload) applied per endpoint. An endpoint with no policy is an authenticated endpoint, not an open one.
• Every client-scoped request is resolved, not trusted. The client a request belongs to is derived server-side from the signed-in account, and every query is filtered by it. A request cannot name a client it does not belong to.
• Least privilege for invited users. A portal user invited by a client is created read-only and cannot administer the client's environment unless the client explicitly grants that role.
• Access removal is complete. Removing a user's access deactivates the link to the client and disables the identity provider account, so a removed user cannot sign in.
• A lapsed subscription stops access, not capture. Where a subscription is not active, portal and upload requests are refused with an explicit payment-required response and the device keeps the records queued, so nothing is lost and nothing is silently dropped.

3. Audit and traceability

• Administrative and client actions are written to an audit trail with the actor, the entity changed and the time.
• Access events record which device captured them, when, and the outcome, so a decision to admit or refuse a person can be reconstructed after the fact.
• Requests are logged with method, path, status and duration, which supports incident investigation.

4. Data protection

• In transit: all traffic between devices, portals and the API is carried over TLS, and uploads are retried from a durable queue rather than lost.
• This website and the platform: the site is served with a strict content security policy, transport security, referrer, permissions and frame policies, and it sets no cookies and loads no third-party script. Access records are stored in PostgreSQL with per-client scoping, and monetary columns use fixed precision. Business dates are normalised to UTC so that a document expiry cannot be misinterpreted by a time zone.
• On the device: captures are written to a local SQLite database first, so a gate keeps working with no network at all. Records are removed from the device once they have been uploaded, and a record that the server refuses is retained with the reason attached instead of being deleted.
• Card data: card payments are processed by a payment service provider. The platform stores only the last four digits and the provider reference, never the full card number. This deployment currently uses the provider's sandbox, so no live card is charged.
• Secrets: credentials for the database, the identity provider and the mail server are supplied to the running service through its environment and are not part of the application source.

5. Availability and recovery

• Offline-first capture at the gate is the primary availability control: no network outage, load-shedding event or platform restart stops the gate from recording who came through.
• The API exposes separate liveness and readiness health checks so a supervisor can restart an unhealthy instance without touching a healthy one.
• Database migrations run as a controlled step at start-up rather than being applied by hand.

6. Not yet in place

We would rather list these than have you discover them during an audit:

• No formal certification. ACS does not hold ISO/IEC 27001 or SOC 2. Preparing for an independent assessment is a roadmap item, and we will share the current state with your reviewers in writing.
• No independent penetration test of the platform and the mobile capture application has been completed yet.
• Encryption at rest relies on the disk encryption of the hosting platform. Application-level encryption of individual record fields (for example, identity numbers held in a separate key scope) is on the roadmap but not implemented.
• No uptime or error monitoring. There is no external availability check or crash reporting on the platform or the website, so an outage tends to be noticed by a customer before it is noticed by us.

7. Reporting a vulnerability

If you believe you have found a security weakness in ACS, contact [security contact email] with enough detail to reproduce it. We will acknowledge your report within two business days, keep you updated while we investigate, and agree a disclosure timeline with you before any public write-up. Please do not test against a customer's live gate or attempt to access records that are not yours.

Machine-readable contact details are published at /.well-known/security.txt.