Account Factory delegates routine identity lifecycle and dormant-account governance for the volunteers, trustees, contractors and service accounts your HR-driven provisioning was never built for – all in your own Entra tenant, with a clean, audited record of who did what. No per-seat licence. No vendor control plane.
az login to a running instanceA charity might have a few hundred payrolled staff and thousands of volunteers – yet it is exactly that population, the people HR never knew about, that automated provisioning does not cover. And plenty of organisations have no automated provisioning at all: HR API-driven and SCIM connectors are relatively advanced, so every account is still created by hand. Either way, volunteers, trustees, contractors, agency staff, shared and service accounts all become manual tickets.
Locked-down profiles, least-privilege roles, and a tamper-evident audit trail – the guardrails travel with every action, so delegation never means losing control.
No IT ticket for routine joiners, movers and leavers. Everyday account work goes to the people who actually know the person.
Define the account shape once and apply it consistently. Editing a profile mints a new version; existing users keep theirs.
Least privilege that matches how teams actually work. Nobody gets more power than their job needs.
Continuous access review for low-touch populations, driven by the one person who actually knows whether an account is still needed: the manager.
Nothing mutates silently. Every create, modify, delete, take-over, TAP issue, config change and sign-in writes a structured row.
New joiners get a secure first sign-in with no shared password. Secrets are encrypted at rest and auto-purged on expiry.
Bring an existing estate under management safely, and stand up new cohorts in bulk without importing mess.
For adopters still running AD, extend the same lifecycle and audit model on-prem – then help turn that side off.
Per-tenant deployment, runtime config, and update awareness – no redeploy to change a setting, no remote kill switch.
What a delegated business user actually does, end to end – with every step running against a locked profile and written to the audit log.
Create from a profile in a few guided steps.
managedBy = AccountFactory, assign groups, issue a TAP if passwordless.Modify in place, with identity preserved.
One action to offboard cleanly.
A daily worker keeps owned accounts from lingering unused – manager confirmation without buying an identity-governance licence for every user.
Finds app-managed accounts inactive 30 days, skipping new, disabled, and excluded accounts.
"Still needed" / "no longer needed" links via ACS. A positive reply resets the clock.
No manager response routes to the scoped Profile Administrator(s) for that population.
Still no response soft-disables the account and routes it into the leaver flow.
Every email, response and timer transition is written to the audit log; the worker is safe to re-run.
The distribution and security model is built around one principle: the adopting organisation keeps full custody of its own directory, its own credentials, and its own infrastructure. There is no shared SaaS platform and no vendor-held control plane – deliberate, because a tool that creates and deletes identities should never be remotely disablable.
Each org runs its own single-tenant instance with its own app registration, admin consent and audit trail. No shared multi-tenant hosting – it is explicitly out of scope.
No secrets in source, ever. The App Service authenticates via managed identity; certificates and credentials live in Key Vault, not the database. SQL TDE is on, with column-level encryption for TAPs, PINs and PDF bytes.
The managedBy = AccountFactory marker gates every mutation. Mover and Leaver refuse to act on accounts the app does not own; reads stay unrestricted within scope.
Read, audit and fork the code under a restrictive licence. A prospective adopter can even take time-limited read access to audit it first.
No developer-hosted licensing or update server. The app never phones home for permission to run and contains no remote kill switch.
Scoped Graph permissions, each tied to a stated purpose, and a deliberately weak read-only identity for directory readiness – the weakest of the on-prem identities.
Account Factory creates, modifies and deletes identities, and in hybrid mode it also holds an on-premises service account that can write to Active Directory and Exchange. That makes it a privileged, control-plane application, and it straddles two boundaries a security team is right to guard: the seam between on-premises AD and Entra ID, and the line between IT administration and the delegated business users it hands lifecycle actions to. We will not pretend otherwise – the design assumes the tool itself is a target.
It runs in your own tenant and subscription, so it adds no new external trust boundary and no third party with standing access to your directory. There is no vendor to breach in order to reach you.
The managedBy = AccountFactory marker gates every write. Even a fully compromised instance cannot rewrite arbitrary objects or privileged groups it does not own – it is not a general directory-write oracle.
The AD and Exchange surface – the part that actually crosses the on-premises to cloud boundary – sits behind a single master switch, disabled for cloud-only adopters, and is transitional by design: built to shrink that boundary, then be switched off.
Six least-privilege roles, scope evaluated server-side on every read, an Auditor with no write power and a Help Desk that cannot create. Delegation is bounded, never a blank cheque.
Every state change writes to a tamper-evident audit log the app cannot silently rewrite, and the privileged code path is readable and forkable – open to inspection, not a black box.
It cannot deploy itself, carries no kill switch and never phones home. Nobody outside your tenant, the developer included, can reach the privileged surface.
Do not take our word for it. The full attack surface – the architecture, the exact Graph and on-premises permissions and why each one is needed, the owned-writes gate, the audit schema and the AD master switch – is written down for you to review before you adopt. Read the specification.
If you are mid-migration, Account Factory extends the same lifecycle and audit model onto the on-prem side, then helps you turn that side off. This entire surface sits behind a single AD master switch – cloud-only adopters simply leave it disabled.
An interactive wizard stands up the whole instance against a single az login – idempotent, and it shows a plan and cost estimate before it provisions anything.
az loginAuthenticate to your own Azure subscription and Entra tenant. Nothing org-specific ever leaves your environment.
npm run setupLaunch the interactive wizard. It creates the resource group, six role groups, the single-tenant app registration with API scope, group claims, Graph permissions and admin consent, plus a Key Vault-stored certificate and OIDC credentials for CI/CD.
The wizard shows a plan and cost estimate before it deploys the Bicep stack – App Service, Azure SQL (Free Limit), Key Vault and Communication Services – and is idempotent on re-run.
Commit to your fork. GitHub Actions ships the app to App Service over OIDC; schema migrations run idempotently on startup.
Updates always pass through your own pipeline and change control. The running app holds no rights to deploy.
You pay only your own Azure consumption. There is no licensing server and no usage metering by the developer.
On baseline SKUs using the Azure SQL Free Limit. The stack is mostly idle, so a B1 App Service plan and auto-pausing serverless SQL keep it cheap. The deployment wizard shows a cost estimate as part of the plan, before anything is provisioned.
The hybrid figure covers VNet integration, NSGs, private DNS and read-only DC access, and only applies if you turn on the transitional AD / Exchange path. Cloud-only adopters skip all of it.
Enterprise-credible, but human – it speaks to overstretched teams, not procurement committees. The people who own the tenant, and the organisations whose directory is full of people HR has never heard of – whether they run HR-driven provisioning that never reached those people, or have no automated provisioning at all.
The people who own the tenant, run the AD-to-Entra project, and field every "can you create an account for our new volunteer?" ticket. They want the routine cases off their desk and a clean, audited record – without standing up a heavyweight IGA platform.
Organisations whose "edge case" population is often bigger than the payrolled one – a charity with a few hundred frontline staff but thousands of volunteers. Cost-sensitive, lean IT, and wanting something they can read, audit and run themselves.
Honest over hyped – what it does, and what it deliberately does not.
Delegate account creation. Keep the audit trail. Read the spec, or request time-limited access to the source to audit it before you commit.
Tell us a little about your organisation and we will be in touch about read access to the source and running it in your own tenant. No obligation.
We will be in touch shortly. If it is urgent, email info@ciaas.com.