The challenge behind the engagement.
Enterprise Identity Architecture is for organizations whose workforce identity grew by accretion: directories and sign-in systems added through mergers, synchronization links nobody documented, and access policies nobody owns. We inventory every identity store and how it synchronizes, export the current access policies and registered sign-in methods, and list applications by how they connect to identity. We review privileged access against a model that separates everyday accounts from the ones that control the environment, then trace how ordinary accounts chain into administrative control. You receive current and target state diagrams, a named access-policy set, a role model with just-in-time access rules, and a migration plan staged behind a monitoring-only mode before enforcement. We work from read-only access; your operators make each change.
For identity and infrastructure leads at organizations running one or more workforce identity systems across cloud and on-premises. The trigger is usually a merger, an enforcement deadline that broke automation, or a customer questionnaire about how privileged access is controlled.
What we do.
What you can use.
Collect the identity estate read-only
We ask for read-only reviewer access in each identity system, plus directory read rights to enumerate groups and permissions where an on-premises directory exists. We also need sign-in and audit log exports, current diagrams, and the system that holds your employee records. Application owners get a short interview each.
Map privilege and policy as it exists
We enumerate the highest-privilege roles in each system, standing versus on-demand assignments, break-glass accounts, outdated sign-in methods still in use, and every access policy with its exceptions. We then show which permissions, group memberships, and synchronization accounts chain together into administrative control.
Design and stage the target state
You receive the target state: automated joiner, mover, and leaver flows driven by your employee records, a group and role model, and just-in-time access rules. Access policies are built from named signals, such as device health, sign-in strength, and login risk. The migration plan runs in monitoring-only mode first, pilots by group, and records each rollback.
Who it’s for.
When you need it.
- Enterprises whose workforce directory grew through mergers into overlapping stores nobody fully owns
- Identity and infrastructure teams running a hybrid of on-premises directories and cloud identity providers
- Organizations carrying standing administrative privilege with no just-in-time or access-review discipline
- Security leaders who must show customers how workforce access and privilege are governed
- An MFA enforcement deadline just broke automation or service accounts in production
- A merger or acquisition added another directory or tenant to govern
- A customer or insurer questionnaire asks how privileged access is controlled
- Leavers keep access for weeks because joiner, mover, and leaver flows are manual
What the scope can include.
- 01
Inventory of directories, sign-in systems, and cloud access with their synchronization topology
- 02
Export and review of every access policy, its exceptions, and outdated sign-in methods still allowed
- 03
Standing versus on-demand privileged role membership across directories and cloud platforms
- 04
Analysis of how ordinary accounts chain into administrative control
- 05
Application inventory grouped by how each one connects to identity
- 06
Decision on how to synchronize identity across on-premises and cloud, including separated environments
What it typically costs.
One rate: $150/hour.
Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and the final deliverables included. Find the size closest to yours.
One directory and sign-in system, a few hundred staff
About 40–72 hoursOffice and cloud directories kept in sync, up to a few thousand staff, dozens of apps
About 90–150 hoursSeveral directories inherited through acquisitions, thousands of staff
About 180–300 hours- Number of directories and sign-in systems to inventory
- Number of staff and connected applications
- How many administrator roles and privileged accounts exist
- Undocumented sync links or policies that must be reconstructed
2–3 weeks for a single directory; 6–10 weeks for a multi-directory enterprise
Get a fixed quote for your scopeRanges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.
What you take forward.
- Current and target state diagrams mapped to recognized identity maturity stages
- Named access-policy set with owners, exceptions, and the licensing each policy requires
- Privileged access model with just-in-time access rules, a break-glass runbook, and secure administration requirements
- Migration plan with monitoring-only stages, pilot groups, retirement of outdated methods, and rollback
Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.
Before we get started.
We still run older on-premises directories and federation. Do you force a cloud-only design?
No. The target state is decided by your applications, not by a preference. Applications tied to older on-premises protocols keep a local directory; we then decide which synchronization approach fits, since modern options handle separated environments. Aging federation services are retired only when every connected application has a tested replacement, with the cutover staged one application at a time. The plan records what stays on-premises, why, and the hardening it needs, such as controller baselines and secure administration hosts.
Will access policy changes lock out administrators or break service accounts?
That is the failure we design against. Every new policy runs in monitoring-only mode first, and we read the sign-in log to see who it would have blocked before it is enforced. Break-glass accounts are excluded and tested. Personal accounts being used as service accounts are listed separately, because stronger sign-in requirements increasingly reach them and they should move to dedicated machine identities. Pilots go group by group, and each step has a written rollback.
- NIST SP 800-63-4: Digital Identity Guidelines
- NIST SP 800-207: Zero Trust Architecture
- Zero Trust Maturity Model | CISA
- OWASP Non-Human Identities Top 10
- Securing privileged access Enterprise access model - Privileged access | Microsoft Learn
- What is Microsoft Entra Agent ID? - Microsoft Entra Agent ID | Microsoft Learn
- RFC 9700: Best Current Practice for OAuth 2.0 Security