Hybrid Identity Attack Path Assessment and Admin Tiering

No, and we put that in writing because the distinction has contractual teeth. A penetration test exploits weaknesses to demonstrate impact and often carries accreditation requirements. This assessment analyzes your tenant, directory, devices and Azure configuration against the same paths a competent attacker would follow — without exploiting anything — and tells you what to fix in what order. If your obligation names a penetration test by a certified firm, commission exactly that. Many clients run this assessment first, so the test they pay for finds something interesting rather than a service principal with a five-year-old secret.

The full assessment of one Microsoft Entra tenant and one Active Directory forest across every path family listed above, the scored findings report, the target tiering design and the design workshop, the agreed quick wins implemented during the engagement, the sequenced roadmap, and both sessions — technical and executive. Fixed price, quoted in writing before we start; you pay after you approve delivery. Additional tenants or forests, and unusually large Azure or device estates, are agreed and priced at scoping rather than discovered in week two.

Different estate, different question. The Active Directory Security Assessment goes deep on the on-premises directory — delegation in all three flavours, kerberoastable accounts, krbtgt password age, AD CS templates, legacy protocols, Group Policy hygiene — and answers "how does someone become Domain Admin?". This engagement answers "how does someone become Global Administrator, or reach control-plane privilege, from anywhere in the hybrid estate?", which runs through Entra roles, applications, Intune, Azure RBAC and the synchronization seam. If you have no meaningful cloud administrative footprint, start with the AD assessment. If you have both, most organizations do this one first, because the cloud paths are the ones nobody has ever inventoried.

No. Where it is available in your tenant we read its attack paths, choke points and critical-asset coverage as one input; where it is not, the assessment runs on direct exports of your roles, groups, applications, RBAC and directory configuration. It is worth knowing what the tooling needs to be useful: Microsoft licenses these features through Microsoft 365 E5, E3 with certain add-ons or Defender suite licenses, and states that full value depends on Defender for Cloud with CSPM and Defender Vulnerability Management, that attack paths may be incomplete without licenses for the workloads involved and defined critical assets, and that the service is public-cloud only. Its non-Microsoft data connectors are in preview at the time of writing and carry consumption-based charges once generally available — Microsoft's charges, on your bill, not ours.

Read-only, time-bound access that you create and revoke: directory and security reader roles in Microsoft Entra and the Defender portal, Reader at the Azure scopes you nominate, a read-only Intune role, and a read-oriented account for the on-premises directory. Collection changes nothing. The only changes made during the engagement are the quick wins, and those are agreed item by item beforehand, low-risk and reversible by design, and executed through your change process with before-and-after state recorded. We never ask for standing Global Administrator — and a provider assessing your privileged access who does is itself a finding.

Tiering keeps control of the systems that grant access separate from the systems that consume it, so a phished helpdesk account cannot become a tenant administrator by lunchtime. Microsoft's enterprise access model is the current expression of it: the old Tier 0 expands into a control plane — identity systems and anything that can administer them — while Tier 1 splits into a management plane for enterprise-wide IT functions and a data/workload plane for per-workload administration, and Tier 2 splits into user access and application access. The point is the hierarchy: control of a higher plane must not be obtainable from a lower one. The design assigns your roles, groups, applications, servers and administrators to planes and states what would violate the model.

Usually quite a lot, because PIM governs one hop. It makes a human's role activation time-bound and approvable; it does not tell you which application permissions can grant a directory role, who owns the role-assignable group behind an eligible assignment, who can reset an administrator's authentication methods, who can push software to the workstation that administrator signs in from, or who holds Owner on the subscription running your synchronization server. Those are all one-hop routes into the same privilege, and PIM does not see them. If the assessment finds PIM itself is the gap — permanent assignments everywhere, no approvals, no emergency access design — the follow-on is Microsoft Entra PIM and Privileged Access Hardening.

No, deliberately. Implementing a tiering model touches accounts, workstations, policies, approval habits and several teams' daily work; it is weeks of change management, and pretending it fits inside a two-week assessment would shortchange both. What you get is a design your team can execute, a roadmap sequenced by risk removed against disruption caused, stage one concrete enough to start the following week, and the agreed quick wins already done. Implementation is separately scoped — the PIM and privileged-access work as one engagement, the admin workstation build as another — and you are free to do all of it in-house.

Microsoft publishes reference points — fewer than five Global Administrators and fewer than ten privileged role assignments — and they are a reasonable target for most mid-market tenants. But the count alone is a poor measure. A tenant with three Global Administrators and eleven applications that can grant directory roles is in a worse position than one with six administrators and a clean application estate. The report gives you the numbers, and then the paths, because the paths are what an attacker actually walks.

Three things. What they can do: the Microsoft Graph and Azure permissions that matter for escalation — the classes that can grant directory roles, assign further application permissions, or add credentials to other applications — plus any directory role or Azure RBAC assignment held by a service principal or managed identity. Who can become them: application owners, and everyone who can add a secret, certificate or federated identity credential, because that is equivalent to holding the application's privilege. And whether they should still exist: credentials with distant expiry on integrations that were decommissioned, consent grants nobody remembers approving, and applications with no owner at all. Each one is dispositioned as needed, reducible or removable — and the removable ones are candidates for quick wins.

It depends entirely on whose passwords, and Microsoft's role design draws the line for you: resetting credentials or authentication methods for members and owners of a role-assignable group — or for other administrators — requires a higher privilege than resetting an ordinary user's. If your helpdesk role can reset an administrator's password or re-register their MFA, that is a path from a first-line account to the control plane, and it will be in the report with the fix. Often the fix is not "take the rights away" but scope: administrative units, a separate model for privileged accounts, and — where the friction is justified — restricted management administrative units that put emergency access and executive accounts out of tenant-wide reach.

No — mid-migration is exactly when hybrid paths multiply, because both worlds are live and each trusts the other. The synchronization server, the writeback and Password Protection agents, the NPS extension host and any federation trust are all control-plane assets while they exist, and Microsoft's guidance is explicit that no on-premises account should hold administrative privilege in Microsoft 365. The assessment is also useful as migration input: it tells you which on-premises dependencies must be retired before cloud administration can be considered contained, and which can be left to the project's normal pace.

Yes, quoted per estate. The fixed $3,950 covers one Microsoft Entra tenant and one Active Directory forest. Multi-tenant organizations — common after acquisitions — and multi-forest environments add collection effort and, more importantly, cross-boundary analysis: cross-tenant access settings, guest privilege between tenants, and forest trusts that carry administration. We scope that at the start and price it in writing before any work begins, rather than raising it once we are inside.

We stop assessing, tell you immediately through the agreed contact, and help you engage a proper incident-response process while preserving evidence rather than trampling it. An assessment quietly upgraded into incident response serves neither purpose, and you deserve to know the moment the engagement changes character. To be clear about the limits: this is not a compromise assessment, and a report with no such finding is not a statement that your tenant is clean.

Annually as a baseline, and after anything that reshapes privilege: an acquisition or tenant consolidation, a large Azure or Intune program, a migration off on-premises Active Directory, or turnover among privileged staff. The second assessment is normally faster to act on, because the tiering model already exists and the question becomes "what drifted?" rather than "what is the model?". Between assessments, the continuous half — access reviews, stale accounts and guests, application credential expiry — is ongoing hygiene work rather than a project.