Joiner · Mover · Leaver intelligence
Avertari watches your HR system and identity provider for joiners, movers and leavers, then tells you exactly what access should change, and why. It works alongside the tools you already run.
Read-only connectorsNothing changes without approvalUK-hosted
Suggested actions · 3
Suggested actions · 3
Suggested actions · 3
Illustrative example · names and data are fictional
Building connectors for
The problem
Your HR system knows the moment someone leaves. Your identity provider finds out when somebody remembers to tell it.
Accounts, tokens and shared files stay active after the last day. Nobody is watching the gap between HR and IT.
People get new access when they change roles and rarely lose the old. After a few moves, someone has access that no single role would allow.
New starters wait on access requests, or get a copy of someone else's access "to be safe". Either way, it's guesswork.
Joiners, movers, leavers
Avertari connects HR events to real identities and accounts, compares them with what similar people hold, and suggests exactly what should change. Every suggestion comes with the reason for it.
A suggested baseline built from the access held by people in the same role, not a copy of whoever sits nearby.
Role changes suggest what to add and what to remove, so access doesn't keep piling up with each move.
A complete checklist for each leaver, timed to their last day, including the access that SSO doesn't cover.
How it works
Grant Avertari read-only access to your HR system and identity provider. Wherever the vendor supports it, you approve access through their own admin-consent screen, so you don't paste passwords or long-lived keys.
Avertari matches HR events to the identities and accounts they affect, the moment they happen, and compares them with what similar people hold.
You get a clear, explained list of access changes. Approve them, send them to your ticketing tool or dismiss them. Nothing changes without a person deciding.
Security
We're asking to see your identity data, so we've built Avertari to keep what it holds, and what it could do, to a minimum.
Read our security approachConnectors ask only for read scopes. Avertari can't change anything in your systems, so a compromise of Avertari can't either.
We use admin consent or signed-key authentication wherever vendors support it. Where a vendor only offers API keys, they're encrypted with a key unique to your organisation.
Each organisation's data and credentials are separated at the database and encryption-key level, not just in application code.
Customer data is stored and processed in the United Kingdom. Where it lives is enforced by cloud organisation policy.
Design partners
We're working with a small group of IT and security teams on the first connectors. You get early access, direct input on what we build and design-partner pricing. We get your honest feedback.