Built so you can start small and trust us gradually.
We govern identities for a living, so we hold ourselves to the model we'd want as a customer: your data in its own database, a connection that can only read until you say otherwise, and a clean way out. This page is specific on purpose — no badges standing in for answers.
You never have to trust us all at once.
Every stage is real work you can stop at. Nothing writes back to your directory until you explicitly turn it on, per connection.
Isolation and least privilege, by construction.
A database per customer
Every customer gets their own database with its own SQL credentials — not a shared table
with a tenant column. One customer's login cannot read another customer's data, because it
is scoped to a different database entirely. Isolation is enforced by the boundary, not by a
WHERE clause we have to remember to write.
Read-only by default
A connection to your directory can only read until you explicitly enable write-back on that specific connection. Discovery, certification, and reporting never need write access — so for most of what the platform does, it simply cannot change anything in your environment.
Credentials encrypted, never logged
Directory and service credentials you enter are encrypted at rest and decrypted only to make the connection you configured. They are never written to logs, never shown back to you in the clear, and never leave your tenant's boundary.
Encrypted in transit and at rest
All traffic is HTTPS (HSTS, TLS). Data at rest sits on Azure SQL with transparent data encryption. The platform runs in Microsoft Azure; we can confirm the specific region for your tenant on request.
The questions a security review actually asks.
Start where you're comfortable.
Explore the read-only demo, or send us your security questionnaire — we answer specifics.