Security
How we secure AverFirst
We intend to ask institutions to trust us with questions about their own security, so we describe ours plainly: what is in place today, stated so it can be checked. When an independent assessment has been completed, it will be listed here with its scope and date.
Identity and access
Who can sign in, and what they can do once they have.
Multi-factor sign-in is mandatory
Every person enrols an authenticator app before their first session. A correct password alone yields only a five-minute challenge that can do nothing but finish the sign-in.
Passwords and sessions handled with care
Passwords are hashed with Argon2id. Every refused sign-in gets the same answer, attempts are limited per network and per account, and an authenticator code works once. Sessions end after 24 hours of inactivity and after 7 days at most, and every change to a password, an authenticator or recovery codes asks for the password and a fresh code again; changing a password ends every other session.
Least privilege, decided on every request
Access is a set of permission keys resolved from a person’s role on each request, so a change of role takes effect at once. Inside the infrastructure, each component holds only the permissions its own work needs: the application’s database login can read and write rows, and nothing else.
Data protection
Where data lives and how it is protected there.
Hosted in the European Union
The platform runs in AWS’s Frankfurt region (eu-central-1); backup copies are held in a second EU region (Ireland, eu-west-1).
Encrypted at rest and in transit
The database, the cache and the backups are encrypted at rest with keys held in AWS Key Management Service. Connections are encrypted with TLS 1.2 or later from your browser to our edge and from the edge to our load balancer, and the database and the cache accept encrypted connections only.
Secrets sealed record by record
Authenticator secrets are encrypted individually under a managed key, bound to the record they belong to, with an escrow copy sealed to offline keys so that losing a key does not mean losing the data.
Backups and recovery
What survives a mistake, an attacker or the loss of a region.
Point-in-time recovery
The database can be restored to any moment of the last 35 days.
Backups nobody can delete early
Backups are copied into a second AWS region, including a vault under an AWS Backup Vault Lock in compliance mode, which keeps every copy until its retention ends.
A copy outside AWS, proven every week
An encrypted, signed copy of the database and stored files is kept with a storage provider outside AWS under an object lock. A restore drill runs every week and opens it.
Audit and operations
How changes are recorded and how software reaches production.
An append-only audit trail
Sign-ins and every change to accounts and access are recorded in an audit trail the application can add to but cannot alter or delete, enforced by the database itself.
Logs without payloads
Our logs record facts — never a password, a code, a token or the content of a request.
Every change reviewed by the pipeline
Every change lands through a gated merge pipeline that runs the full test suite; each release image is signed, and production is updated only by the deployment pipeline.
In the browser
What our pages allow a browser to do.
A strict Content Security Policy
Our pages run no inline code and load no scripts, styles, fonts or images from any other host. Framing by other sites is refused.
HTTPS only
Every name under averfirst.com is served over HTTPS with a two-year HTTP Strict Transport Security policy that covers subdomains.
No cookies, no tracking on this website
This website sets no cookies and runs no analytics. The console uses only the cookies its sign-in needs.
Disclosure
Report a vulnerability
If you believe you have found a security vulnerability in AverFirst, please tell us through the contact form, choosing Report a security vulnerability. Describe what you found and how to reproduce it, and give a work email we can reply to.
When you research, please:
- use only accounts and data that are yours, and stop as soon as you reach data that is not;
- never degrade the service for others, and never use social engineering or physical access;
- give us a reasonable time to fix the issue before you disclose it.
We will acknowledge your report, keep you informed while we fix it, and credit you if you wish. Our contact details for researchers are also published in /.well-known/security.txt.
Go to the contact formQuestions about our security?
Request a briefing and we will take you through the architecture in as much depth as you need.