TRUST & ARCHITECTURE
A note for IT and security readers. The business benefits described across this site rest on an architecture built for tools that touch identity and access data. Security is a first-class part of the platform, not a bolt-on, and the access model holds to that standard everywhere — not just in the Security module.
A backend-for-frontend layer holds and refreshes the tokens needed to reach the underlying platform and Microsoft Graph. The browser only ever talks to that layer.
There is no separate identity store and no separate password to manage.
Every module's read and write access is resolved per user, per tenant and per legal entity from one central access model — the same model onboarding, security and cost governance all read from. If the platform cannot confirm a right, the default is to hide, not to show.
A manager can be granted rights to onboard and manage access, scoped strictly to their own legal entity and department. Never the whole tenant, never another company's people.
Request, approval and result in one order, with a full history, for every access-affecting change in the estate.
So "has this gotten better or worse since last quarter" is answerable from stored reports, not memory.
[FILL IN: hosting region and provider · data retained (identifiers, assignments, order history) · encryption in transit and at rest · backup and restore practice · sub-processors · data processing agreement availability · how a customer removes the application and what is deleted, and when. None of these facts are in the whitepaper; do not publish this page without them.]
Solver Entra does not replace the Microsoft 365 admin center, Entra ID, Exchange admin or the third-party reporting and auditing tools an IT department already uses; it reads from and writes through them.
[FILL IN: current status of any external security audit or certification — state it only if it is true; otherwise delete this token and say nothing.]