Sign-in built for the job
Passkeys and one-time codes, sessions that live on our server rather than in your browser, and a second check before anything sensitive.
A security vendor asking for access to your website should be able to show how it protects itself. Here is how we run, in plain terms, including the parts that are not finished.
A state is shown as verified only while its evidence is recent. When a check has not run lately, the interface says Unknown instead of staying green.
Every capability has a narrow responsibility, an operational state and evidence that explains the result.
Passkeys and one-time codes, sessions that live on our server rather than in your browser, and a second check before anything sensitive.
Every deployment records its source, its checksums and the exact command to go back — and the way back is rehearsed.
Separation between customers is enforced by the database itself. Request contents, addresses and personal data are not collected for analysis.
The visitor path remains short. Configuration, verification and rollback stay visible to the operator at every stage.
The security contact and reporting channel are published, not hidden behind a form.
Each capability shows what is available, what is only being watched and what is not built yet.
If a state is green without recent evidence, that is a bug — tell us.
AegiFlow does not turn missing evidence into a reassuring zero. Every state links to its source, freshness and next action.
How this capability behaves in production — grounded in the platform's documented, current operation.
Self-hosted identity with passkeys and step-up verification, opaque server-side sessions, immutable releases with checksums and rehearsed rollbacks, encrypted off-site backups with monthly restore drills, and a public security.txt with a real disclosure channel. The Trust Center shows capability states with the same honesty the dashboard shows customers.
Ownership, certificate, origin health and rollback must pass before traffic protection changes.