Why Entra ID and hybrid identity need their own assessment
This assessment tests the Microsoft Entra ID tenant and the on-premises Active Directory link to it as one target, including the Entra Connect or Cloud Sync server as a control plane asset. If a compliance framework, customer security review, product launch or insurer has asked for identity testing, this is the scope to confirm: the cloud tenant, the synchronization path, the sign-in method in use and the on-premises systems that can change identities the cloud trusts. A test of the tenant alone, or of Active Directory alone, leaves the link between them untested, and that link is where many hybrid identity problems sit.
Identity is the control plane for both estates. The sync server holds credentials or trust relationships that let it act on directory objects, so compromising it can reach on-premises and cloud identities at once. Similarly, a privileged Entra role, such as those that manage other roles, applications or conditional access policies, can change access across the tenant and, depending on the configuration, the on-premises environment. Microsoft's enterprise access model is built on the idea that a lower tier must not be able to control a higher one, and that configuration should be audited continuously for paths that enable privilege escalation. A hybrid assessment checks whether those boundaries hold in practice, not only on the architecture diagram.
Configuration drift is common in hybrid identity because the tenant, the sync tooling and the on-premises directory are often changed by different teams over several years. Confirm which synchronization tool is deployed and its version before scoping, since Microsoft has stated that Entra Connect V1 was retired on 31 August 2022, and that Entra Cloud Sync is the future of synchronization. Ask the provider to review privileged role assignments, consent grants to applications and conditional access coverage alongside the sync server build. Those are the items most likely to have changed since the last review, and they are the ones an auditor or customer will ask about first.
What can be in scope for an Entra and hybrid identity test
A hybrid identity test has more moving parts than a cloud tenant review alone, because the sync path links on-premises Active Directory to Microsoft Entra ID. Agree each component below in writing before testing starts, since each one changes what the tester can reach, what accounts they need and what the report covers.
Entra tenants and directory roles
Confirm which tenants are in scope, including production, development and any acquired or subsidiary tenants that trust the same identities. List the built-in and custom directory roles that hold administrative rights, such as Global Administrator and the roles that manage applications, authentication methods and conditional access. Ask who holds permanent assignments versus eligible ones, and whether privileged identity management is enforced. Tenants without a documented owner are a common source of unmanaged privilege.
Entra Connect or Cloud Sync servers
The sync server is a control plane asset: compromise of it can expose on-premises credentials or change cloud objects. Include the host, its operating system, its administrators and its network position in scope. Confirm whether the server runs Entra Connect, Entra Cloud Sync or a legacy build, since Microsoft has retired Azure AD Connect V1 and says Cloud Sync replaces Entra Connect. Record which agent or sync engine is in use and who patches it.
Sync service accounts and their rights
Sync tools use service accounts with replication rights to on-premises directories and, in some configurations, write rights in the cloud. Ask for an inventory of every sync account, its directory permissions, where its credentials are stored and whether it is excluded from interactive sign-in and tiering controls. Testers typically review these accounts from configuration and permissions data first, then validate the riskiest paths with agreed access.
Sign-in method and federation
The sign-in method determines where authentication decisions are made. Password hash synchronization, pass-through authentication and AD FS federation each place trust and failure modes in different components. For federation, include the AD FS farm, its proxy servers and the token-signing certificate. For pass-through, include the authentication agents. Ask which method is active per domain and whether it has been changed recently.
Conditional access and authentication policies
Scope the conditional access policies that gate sign-ins, including MFA requirements, legacy authentication blocks, device compliance conditions and named location exclusions. Ask for a full export of policies and exclusion groups, not only the ones the security team considers important. Exclusions for break-glass accounts, service accounts or executives are frequent weak points and should be explicitly in scope, with agreed handling for any account that must not be locked out during testing.
Enterprise applications and consent settings
Enterprise applications, app registrations and user consent settings determine which third-party software can read mail, files or directory data on behalf of users. Include the tenant's user consent policy, the admin consent workflow, app owners and any applications with high-privilege Graph permissions or credentials that never expire. Confirm whether consent to multi-tenant applications is restricted, and list the applications whose owners the client wants reviewed.
On-premises tiers the sync path touches
Map every on-premises tier that the sync path reaches. Microsoft's enterprise access model places the control plane in Tier 0, and a sync server or its service account that sits in a lower tier can give an attacker a route to the top of the hierarchy. Include domain controllers, AD FS servers and any hosts that administer them, and check whether the model's hierarchy is enforced for those paths. This scope item usually links to the separate Active Directory assessment.
Rules of engagement and test accounts
Agree the rules of engagement in writing before testing, following the planning phase described in NIST SP 800-115. Define whether testers receive read-only access to configuration, a standard user, a privileged account or an assumed-breach starting point, and who approves each step. Specify permitted times, lockout thresholds, a prohibition on changing production policies, and the escalation contact for any unexpected outage. Ask each provider how test accounts are issued, monitored and removed at the end of the engagement.
How the assessment runs, phase by phase
The sequence moves from agreed rules of engagement to a documented view of how the tenant and its sync servers can be abused, then to validated findings the client can fix and retest. Each phase closes with a written output so the client can see what was checked and what was not.
Agree rules of engagement and management approval
The planning phase follows NIST SP 800-115, which asks that rules are identified and management approval is documented before any testing begins. DeployOpen drafts a rules of engagement document based on the template in Appendix B, covering which tenants, subscriptions, sync servers and accounts are in scope, which tests are off limits (such as credential spraying against production users or changes to conditional access), who is the emergency contact, and how testing accounts are created and removed. The step closes when the client's accountable owner signs the rules of engagement. Ask whether the Entra tenant owner and the on-premises AD owner will both sign, since the two sides often sit with different teams.
Map the tenant and hybrid identity footprint
Under the discovery phase, the team identifies what exists before judging it. This means listing the Entra tenants, custom domains, the sign-in method in use (password hash synchronization, pass-through authentication or federation with AD FS), the synchronization tool and the servers that run it, and the applications registered in the tenant. The output is an asset inventory marked with the control plane systems, such as the Entra Connect or Cloud Sync servers, that can influence identities in the cloud. Confirm early whether any Entra Connect V1 installations remain, because Microsoft retired that version on 31 August 2022.
Review configuration of tenant and sync servers
Configuration review checks the settings that decide how identity is protected. Testers examine privileged role assignments in Entra ID, conditional access policies and their exclusions, MFA registration and enforcement, application consent settings and the permissions granted to enterprise applications. On the sync side, they review the service accounts used by the synchronization tool, the administrative tier of the server hosting it, and whether it sits in a tier that matches Microsoft's enterprise access model. Each configuration check is recorded with the evidence used, so a reader can re-run it later.
Identify and map attack paths between planes
Here the team connects the individual settings into paths. The question is whether a lower-privileged identity, a compromised sync server or a consented application can reach a higher plane, such as cloud global administrator rights or domain administration. This follows the enterprise access model's requirement that higher planes cannot be controlled from lower ones. Testers document each path as a sequence of conditions rather than running it to completion. The step closes with a path register that lists each path, its preconditions, the affected identities and the evidence that supports it.
Validate weaknesses without causing outages
Validation confirms which weaknesses are real in the client's environment. Testers use non-destructive checks, such as reading configuration, verifying that a test account can or cannot obtain a role, and confirming whether a sign-in path is reachable, rather than changing production identities or forcing sign-in failures across the tenant. Any step that could lock out users, break synchronization or alter a policy is either avoided or run against an agreed test object. The output is a validation log showing what was tested, when, from where and what the result was, which the client can check against its own monitoring.
Report findings with evidence and fixes
The report presents each finding with its affected objects, the evidence, the business impact in the client's terms and a remediation step that the client's identity team can carry out. Findings are tied to the relevant part of the enterprise access model and, where the client needs it, to the control areas of the framework it is working toward. The report also records what was out of scope or not testable, so the client knows the limits. Ask in advance whether the client needs an executive summary, a technical appendix or both, and whether findings should be delivered through a restricted channel.
Retest fixes and confirm closure
Retest checks whether each agreed fix works and does not introduce a new weakness. Testers repeat the validation for each closed finding, record the result, and mark it as resolved, partly resolved or still open. Retest is usually part of the original quote, but the client should confirm how many retest rounds are included and whether retest of a significant change to the tenant needs a new engagement. The closing document lists the status of every finding, which is the record an auditor or customer reviewer is most likely to ask for.
Weakness categories we check in Entra ID and the sync path
This table maps the weakness categories we examine in a Microsoft Entra ID tenant and its link to on-premises Active Directory against the three ideas in Microsoft's enterprise access model: planes that cannot control higher planes, continuous auditing for escalation paths, and anomaly monitoring. Read each row as a question to answer with evidence from your own tenant, and treat the last column as the reason the gap matters to an assessor or to your own risk owners.
| Weakness category | What it looks like in this target | Why it matters |
|---|---|---|
| Sync server treated as an ordinary server | The Entra Connect or Cloud Sync host sits in a general server group, has broad admin logons, is reachable from workstations or shares administrators with other systems | Control of the sync host can lead to control of synchronized identities, so it belongs in the highest tier of the access model |
| Excessive privileged role assignment | Standing Global Administrator or other highly privileged Entra roles assigned to many accounts, service accounts or groups, with few use of time-limited activation | Broad standing rights widen the blast radius of any single compromised account and make hierarchy between planes hard to enforce |
| Weak or missing conditional access coverage | Admin portals, break-glass accounts or legacy app paths excluded from policies, or policies that are report-only and never enforced | Gaps let a sign-in that would be blocked elsewhere succeed, which undermines the tiered trust model |
| Risky app consent and permissions | User consent allowed for broad permissions, unverified publishers, over-privileged enterprise apps and forgotten app registrations with credentials | Consented apps can act with tenant data and sometimes hold rights that rival administrator roles, and they often sit outside normal review |
| Legacy authentication paths | Protocols that do not support modern MFA still enabled for some users, service accounts or mailboxes | Legacy sign-in can bypass MFA and conditional access, so one weak path can defeat otherwise sound controls |
| Federation trust configuration | AD FS or federated domain settings, signing certificate handling, trust scope and who can change federation settings | A federation trust can let an on-premises actor issue sign-ins the cloud accepts, so changes here are a control plane concern |
| Entra Connect V1 still in use | An installation of the retired V1 version still running, or an unclear inventory of sync engines and their versions | Microsoft retired V1 on 31 August 2022 and warns that these installations may stop working unexpectedly, so ownership and patch status must be confirmed |
| Monitoring and audit gaps | Sign-in and audit logs not retained or forwarded, no alerts on role changes, consent grants or sync server logons, and no owner for reviews | Without anomaly monitoring, escalation through the sync path or consented apps may go unnoticed until after impact |
How the test changes by identity architecture
In a cloud-only tenant, user identities are created and governed directly in Microsoft Entra ID, with no on-premises directory feeding them. The assessment centers on the tenant itself: who holds privileged Entra roles, how those roles are assigned and reviewed, and whether conditional access policies cover administrators, legacy authentication and risky sign-ins. App registrations, enterprise applications and user consent settings are usually the largest source of exposure, because a single over-permissioned app can reach mail, files or directory data. There is no sync server to test, so the review is configuration-led and relies on tenant-level evidence.
- Privileged role sprawl: Standing assignments of global or application administrator roles, and whether privileged identity management is used for eligibility and approval.
- Conditional access coverage: Gaps for administrators, service accounts and legacy protocols that bypass modern authentication controls.
- App consent and registrations: Whether users can consent to broad permissions and who owns high-privilege app credentials.
- Emergency access accounts: How break-glass accounts are protected, monitored and excluded from policies that could lock out the tenant.
Confirm with your environment whether any legacy on-premises directories or applications still authenticate against this tenant, since that would bring a hybrid component back into scope.
With password hash synchronization, Microsoft Entra Connect copies a hash of each on-premises password to Entra ID, and sign-in validation happens in the cloud. The sync server becomes a high-value control plane asset, because it holds credentials with directory replication rights and can influence which accounts reach the cloud. The test therefore includes the sync host, its service account, its database and its administrative path, alongside the Entra tenant. The on-premises Active Directory tier model is relevant here, since a compromise of the sync server can translate into cloud privilege.
- Sync server placement: Whether the server sits in Tier 0 with administrative access restricted to tiered accounts.
- Sync account permissions: The directory replication rights granted to the sync service account and whether they are broader than required.
- Sync scope filtering: Whether privileged or administrative on-premises accounts are synchronized to the cloud when they should not be.
- Version currency: Whether the sync engine is on a supported release, given that Entra Connect V1 was retired on 31 August 2022.
Confirm with your environment whether Entra Connect is still in use or whether Cloud Sync has been deployed, and who administers the sync host.
With pass-through authentication, sign-in passwords are validated against on-premises Active Directory by lightweight agents that sit between the cloud and the domain controllers. Password hashes are not stored in the cloud in this model, but the agents create an inbound path from Entra ID that must be tested for exposure and trust. The assessment covers the agent hosts, their network reachability, the domain controllers they reach, and the authentication failure and lockout behavior that flows back to the cloud. The agent hosts are control plane assets in their own right and need the same tiering review as sync servers.
- Agent host hardening: Patch level, local administrator membership and whether the hosts are dedicated to this function.
- Network reachability: Which domain controllers the agents can reach and whether firewall rules permit more than the required paths.
- Agent redundancy: Whether more than one agent is deployed, since a single agent is a point of failure for sign-in.
- Lockout and brute force protection: How smart lockout and sign-in throttling behave when requests reach on-premises systems.
Confirm with your environment how many agents run, which domain controllers they use, and whether any agent host also serves other workloads.
With AD FS federation, Entra ID delegates authentication to on-premises federation servers, which issue the tokens that the cloud accepts. This model has the largest trust surface, because a compromised federation service or its token-signing certificate can allow an attacker to mint tokens for any federated identity. The test covers the AD FS farm, its web application proxies, the token-signing and token-decrypting certificates, the configuration database and the service account. Monitoring and certificate lifecycle management carry more weight here than in the other models.
- Token-signing certificate protection: Where the signing key is stored, who can export it and how rotation is handled.
- Federation server and proxy exposure: Which endpoints are published to the internet and how they are authenticated and patched.
- Federation service account rights: Whether the service account is confined to the farm and kept out of general administration.
- Authentication logging: Whether federation sign-in and token issuance events reach a security monitoring platform.
Confirm with your environment whether AD FS is still required for specific features, since Microsoft's guidance on moving away from federation is a planning question for your identity team and not a finding this assessment can settle alone.
What drives the cost and duration of an identity assessment
This table lists each component that shapes the price and schedule of an Entra ID and hybrid identity assessment, who is paid for it, and what to request in a written quote. Read it against your own tenant and sync estate to see which items will move your quote most. No fixed prices or durations are given, because the quote follows from the agreed written scope.
| Cost component | What it covers and who is paid | What raises or lowers it | What to ask for in a quote |
|---|---|---|---|
| Tenants and subscriptions | Tester time to map each Entra tenant, its linked Azure subscriptions and any B2B or multi-tenant relationships. | More tenants, subscriptions or cross-tenant trusts increase review time. A single tenant with one subscription keeps it lower. | A named list of tenants and subscriptions in scope, and whether guest or partner tenants are excluded. |
| Sync servers and forests | Review of each Entra Connect or Cloud Sync host, its service accounts and its connection to on-premises AD forests. This is one-time for the assessment. | Number of forests, Entra Connect V1 installations, staging servers and federation servers (AD FS) raise effort. Retired V1 installs may also need migration advice. | Count of sync servers, forests, AD FS farms, and the sync method in use (password hash sync, pass-through authentication or federation). |
| Privileged roles | Review of Entra directory roles, Azure RBAC assignments and PIM settings. Largely one-time, with a recurring check if roles change often. | Number of privileged role holders, custom roles and standing versus eligible assignments drives the review. | Count of privileged roles and holders, whether PIM is deployed, and whether custom roles are in scope. |
| Conditional Access policies | Analysis of policy logic, exclusions, named locations and gaps against sign-in risk. One-time review, with retest after changes. | Number of policies, exclusion lists and legacy authentication paths raise effort. Simple baselines take less time. | Policy count, export or read-only access to policy definitions, and whether report-only policies are included. |
| Enterprise applications and app consent | Review of enterprise app registrations, consent grants, owner assignments and permissions granted to users and apps. | Number of apps, user consent settings and high-privilege Graph permissions raise effort substantially. | Application count, consent policy settings, and whether app secrets and certificates are reviewed. |
| Sign-in methods | Assessment of MFA methods, passwordless options, legacy protocols and federation trust configuration. | Mixed MFA methods, legacy protocols and multiple federation trusts increase test depth. | List of enabled authentication methods and whether legacy protocol sign-in is still permitted. |
| Access level (read-only or privileged) | Read-only review is typically lower effort than testing with a privileged test account or from a sync host. The client sets the access they approve. | Privileged access needs more approvals, monitoring and rules of engagement, which adds planning time. | Written access model: read-only, reader roles, or supervised privileged testing, with named account owners. |
| Test depth and approach | Configuration review only, or review plus attempted abuse paths within agreed rules. Covers the planning, discovery, attack and reporting phases described in NIST SP 800-115. | Adding attack path validation, sync host testing or social engineering increases effort. Configuration review alone is narrower. | Stated depth for each component, the rules of engagement, and whether attack paths are validated or only identified. |
| Environment access and coordination | Time for access setup, change windows, identity team sessions and any production safety controls. Paid as project management and tester time. | Number of admin contacts, change approval steps and whether a staging tenant is available raise coordination effort. | Named contacts, access provisioning steps, testing windows and who approves production activity. |
| Retest | Verification that fixes to tenant configuration or sync servers work. Usually billed separately from the first assessment. | Number of findings, the time since the first test and any major tenant changes affect retest size. | Retest included or priced separately, the retest window, and how evidence of fixes is handled. |
What the client receives and whether it satisfies an auditor
A hybrid identity assessment produces a set of linked deliverables, not a single score. Each one answers a different reader, from the identity team fixing configuration to the auditor or customer reviewing evidence. Ask for the report format and evidence standard in writing before testing starts, because the auditor, not DeployOpen, decides whether the material is sufficient.
Executive summary and scope record
The summary states which tenants, sync servers, sign-in methods and privileged roles were in scope, along with the date window and the agreed rules of engagement. It should name what was excluded, such as unlicensed tenants or third-party federation providers, so a reader can see the limits of the result. Check that the scope matches the written statement of work, since the scope record is the first thing an auditor compares against the environment.
Findings with severity ratings
Each finding names the weakness, the affected Entra ID or Entra Connect component, the severity rating and the business impact in plain terms. Findings on the sync path, such as a sync account with more rights than it needs, belong in a separate group from conditional access gaps so owners can route them. Ask how severity is calculated and whether the rating reflects your environment or a generic model.
Configuration evidence
Evidence includes exported settings, role assignments, conditional access policy definitions, consent grant listings and sync configuration as read at test time. Auditors use this material to confirm that a control existed and was checked, so it should show the object, the value and the date read. Confirm with your auditor which screenshots, exports or log extracts they accept and whether personal data in exports must be redacted.
Attack path narrative at a defensive level
This section explains how a weakness could chain into control of the directory, such as a path from a sync server to privileged roles, described as a sequence of conditions and defensive breakpoints. It deliberately omits working commands and payloads. Its purpose is to help the identity and platform teams prioritize the fixes that break the chain, and to show leadership why a medium finding can matter.
Remediation guidance and retest results
Remediation guidance assigns each finding a recommended fix, an owner role and a verification step that the team can check after the change. A retest then confirms which findings are closed, which remain open and which were changed but not fully resolved. Ask whether retest is included in the fixed scope, how long it must follow remediation and whether the retest report replaces or supplements the original.
Letter describing the work
A letter for customers or auditors describes the test type, scope, method, dates and the qualifications of the team in neutral terms. It does not claim certification, attestation or compliance, because DeployOpen does not issue those. Ask your auditor or customer security team what wording they will accept before the letter is drafted, so the document supports the review rather than overstating it.
How to prepare and how retesting works
Preparation decides how much of the test time goes to finding weaknesses rather than arranging access. Before work starts, the client should name an Entra administrator and an Active Directory administrator who can answer questions about the tenant and the domain in real time, and who can approve any change that the tester's findings touch. The tester needs a privileged account for the Entra tenant that is read-only or time-boxed, with the expiry set in writing and agreed in the rules of engagement, so that the review of Global Administrator and other privileged role assignments does not depend on standing high-privilege credentials. Access to the Entra Connect or Cloud Sync servers should be arranged through a named jump path with local logging, and the client should confirm which sync method is in use (password hash synchronization, pass-through authentication or federation with AD FS) so the scope matches the actual sign-in design.
Clients should also hand over three lists before kickoff: conditional access policy and app consent changes made in the last period, recent role assignment changes, and any new enterprise applications or service principals that were granted broad Microsoft Graph permissions. These lists tell the tester where to look first and reduce the chance that a change made during the test is mistaken for a finding. If a change freeze is needed, for example around a quarter-end or a tenant migration, agree the window in writing and record who may approve an exception. Emergency contacts should include someone who can disable a sync or revoke a consent grant at short notice. Ask the provider to confirm how the rules of engagement cover stopping the test if a sync fault or lockout appears.
Retesting checks whether remediated items are fixed, and it compares each one against the original finding, its evidence and the agreed risk rating. It is normally scoped and priced separately from the first test because it is a narrower exercise with a defined list of items, and the client should ask the provider to state in writing which findings are covered, what evidence will be produced and whether any new configuration in the tenant will be reviewed. Changes to conditional access or sync settings made after the first test can introduce new issues, so a retest that only confirms old items may not show the current state. Ask for a retest statement that names the findings, the retest date range and the evidence format, so it can be shared with an auditor or a customer's security team.
Questions buyers ask before commissioning an Entra ID assessment
How much does an Entra ID and hybrid identity assessment cost?
No fixed price applies, because the quote follows from the written scope. The main cost drivers are the number of tenants, the number of on-premises domains and forests linked to them, whether Entra Connect or Cloud Sync servers are in scope, how many applications and consent grants need review, and how much privileged role and conditional access configuration must be traced. Most engagements are fixed-scope, so the fee covers agreed deliverables and is one-time for the assessment itself. Ongoing retesting or continuous review is a separate, recurring cost, usually under a retainer. Ask for the quote to list each tenant, sync server and role group assessed, the testing approach (read-only review, authenticated testing or both), the report format and whether any retest is included.
How long does an Entra ID assessment take?
Duration depends on how much identity configuration exists and how quickly access is granted. The main factors are the number of tenants and synced domains, the size of the privileged role and application estate, the number of conditional access policies, and whether the sync servers are reviewed on site or remotely. Planning and rules of engagement come first, as NIST SP 800-115 describes, so time for scope agreement and approvals should be added to the test window. Ask for a timeline in the written scope that separates preparation, testing, reporting and any walkthrough of findings, and confirm which dates depend on your team.
What does our team need to provide for the assessment?
Your team usually provides a named technical contact, a list of tenants, domains and sync servers in scope, read access or test accounts at the level agreed in the scope, and a change window if any authenticated testing touches production. Expect requests for current Entra Connect or Cloud Sync configuration details, the list of privileged role assignments, conditional access policy exports and the registered application inventory. Confirm in writing who approves the rules of engagement, who is contacted if a sync server behaves unexpectedly and how credentials are issued and removed at the end of the work.
Can our own staff run an Entra ID assessment internally?
Your staff can run configuration reviews against Microsoft guidance, and many teams do this continuously. An independent assessment adds value when the reviewers are not the people who built or operate the tenant, because they can challenge assumptions about privileged roles, sync scope and consent decisions. The key questions are whether your team has staff with current Entra and on-premises AD expertise, whether they can document findings to an auditor's standard, and whether the testing has the organizational independence that some frameworks require. Confirm the skills and independence needed for your framework before deciding.
Does an Entra ID assessment satisfy PCI DSS or CIS requirements?
A test can support a requirement but does not satisfy it on its own. PCI DSS covers penetration testing of the internal and external environment and segmentation controls under requirements 11.4.1 to 11.4.6, and a qualified tester with organizational independence must perform it. CIS Controls v8.1 Safeguard 18.5 calls for internal penetration testing at least annually. An identity assessment can feed evidence into those tests, but whether it counts depends on the scope covering the cardholder data environment and on your assessor's view. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Confirm the scope mapping with your QSA or auditor before commissioning the work.
Is it safe to test production Entra ID tenants?
Read-only configuration review is generally low risk, but authenticated testing against production identity needs explicit rules. The risks include locking out accounts, triggering sign-in protections, changing consent or policy settings by accident and disrupting sync. Agree in writing which actions are permitted, which accounts are used, what is excluded, how testing is paused and who is notified during the window. Many organizations run the most intrusive steps in a staging or dedicated test tenant where one exists. Ask the provider to state how it handles these risks in its rules of engagement.
How does an Entra ID assessment differ from an Active Directory assessment?
An Active Directory assessment reviews on-premises configuration and attack paths, such as privileged groups, delegation, Kerberos settings, Group Policy and tiering. An Entra ID and hybrid identity assessment covers the cloud tenant, its privileged roles, conditional access, app consent and the sync or sign-in link to on-premises AD. The two overlap at the sync servers and the trust between them, because a compromise of a sync server can affect both sides. Microsoft's enterprise access model treats these as part of one control plane, so many buyers commission both together. Ask the provider how it scopes that boundary.
How is retesting priced for an Entra ID assessment?
Retesting is usually quoted separately from the original assessment, and the cost depends on how many findings need verification, how many tenants and sync servers are affected and whether the fixes require a change to the tenant or sync configuration. Ask whether the original quote includes one retest window and how long after the report it remains open. Retests after significant changes, such as a sync topology change or a move from one sync method to another, are usually scoped as new work. Confirm the retest terms in the written scope.
What to check when choosing a provider for identity testing
Identity testing depends on judgment about tenant configuration, sync servers and privileged roles, so the provider's experience matters as much as the method. The cards below cover the questions that separate a credible proposal from a generic penetration test, and they are worth putting to every bidder in writing before a scope is agreed.
Hybrid sync experience
Ask for evidence that the team has assessed Entra Connect and Entra Cloud Sync servers, not only cloud tenants. Confirm they can explain how password hash synchronization, pass-through authentication and AD FS federation each change the attack surface. Ask who on the team has tested the sync account permissions and the server that holds them, and whether that work covered the Entra Connect version in use, since Entra Connect V1 is no longer supported.
Method alignment with NIST and Microsoft
Ask the provider to map their method to the phases in NIST SP 800-115, which cover planning, discovery, attack and reporting. Ask how they test against Microsoft's enterprise access model, including whether they check that control-plane identities cannot be controlled from lower planes and whether they review continuous auditing and monitoring. A provider that cannot name these elements is unlikely to produce a comparable report.
Written rules of engagement
Before testing begins, the rules of engagement should state which tenants, domains, sync servers and accounts are in scope, which actions are prohibited, and who approves changes that touch production identity. Ask whether the provider will test with privileged accounts, and how they will handle lockout risk and emergency stop conditions. Written rules protect both parties if a sign-in failure or a conditional access change reaches users.
Tester independence
Ask how the provider keeps testers independent of the team that built or runs the identity platform. Confirm whether the same firm is also implementing, administering or configuring the tenant. If it is, the report may assess its own work, and your auditor or customer may ask about that. Request a clear statement of any conflict and how it is managed in the engagement letter.
Report samples and findings detail
Request a redacted sample report before you commit. Check that findings on Entra ID and hybrid identity name the affected object or setting, explain the path to privileged roles, rate severity with a stated basis, and give a fix that an administrator can apply. Confirm whether the report includes an executive summary for leadership and a separate technical annex for the identity team.
Retest terms and tenant evidence handling
Agree in writing whether one retest of fixed findings is included, how long it can run after the report, and whether it is priced separately. Ask how tenant data, exported configuration, sign-in logs and sync server details are stored, who can access them, how long they are kept and how they are destroyed. Confirm the provider will not issue any audit opinion or certification, since only independent auditors and certification bodies can issue those.
How DeployOpen scopes, tests, reports and retests identity
This sequence turns a Microsoft Entra ID and hybrid identity assessment into a written, agreed test with findings that engineers can fix and governance teams can read. It also makes clear what evidence DeployOpen produces and what remains the job of an independent auditor or certification body.
Agree written scope and rules of engagement
Before any testing, DeployOpen and the client agree in writing which tenants, subscriptions, sync servers, domains and identity-linked applications are in scope, what testing methods are allowed, who the named contacts are, and how testing is stopped if something unexpected happens. The rules of engagement follow the planning approach in NIST SP 800-115, which expects rules to be identified and management approval documented before work starts. Each assessment is priced from this written scope, so the client can see exactly what the quote covers. The step closes when both parties have signed the scope and rules document.
Collect tenant and sync path configuration
The team gathers read-only evidence on the Microsoft Entra ID tenant and the on-premises directory, including how identities synchronize, whether the link uses password hash synchronization, pass-through authentication or federation, and which sync tool is in place. Teams should confirm whether they run Entra Connect or Entra Cloud Sync, and whether any server still runs an unsupported Azure AD Connect V1 installation. The output is an inventory of identity sources, sync servers and sign-in methods that the client validates before testing begins. The step is complete when the client confirms the inventory matches its environment.
Review privileged roles and control plane assets
Testers examine who holds privileged Entra ID roles, how those roles are assigned and reviewed, and whether the sync servers, their service accounts and their administrators sit within the same tier as the systems they control. This follows the enterprise access model in Microsoft's guidance, which asks that control of a higher plane cannot be reached from a lower one. Findings focus on configuration that allows privilege to move between identity planes. The step closes with a list of privileged accounts, their assignments and any gaps against the tier model, reviewed with the client's identity team.
Validate conditional access and app consent
Testers check whether conditional access policies cover administrative, guest and service sign-ins, whether multifactor authentication applies consistently, and whether legacy authentication is blocked where it is no longer needed. They also review enterprise application consent settings, including which permissions users can grant and which third-party applications already hold broad access to mail, files or directory data. Each check is confirmed by reproducing the configuration state and, where the rules allow, a controlled sign-in test under agreed conditions. The step ends with a validated list of policy gaps and consent risks.
Validate attack paths across the sync boundary
Testers trace whether a compromise of an on-premises identity, a sync server or a federation component could lead to control of cloud identities, and the reverse. Validation is limited to what the agreed rules allow, and each path is confirmed with evidence rather than assumed from configuration alone. Any test that could affect production accounts or sync operations is agreed in advance, with a stop condition and a named contact on the client side. The output is a set of confirmed or ruled-out paths, each with the conditions that made it possible.
Write the report for engineers and governance
DeployOpen issues one report with two readable layers: an executive summary that explains the business effect, control gaps and priorities for governance, and technical sections that give engineers the affected objects, evidence, reproduction conditions and recommended configuration changes. Findings are rated against the client's agreed scale and mapped to the relevant areas of the enterprise access model so teams can track ownership. The report is delivered in a review meeting where the client can ask questions. The step closes when the client accepts the report as the baseline for remediation.
Retest remediated items
After the client fixes findings, DeployOpen retests the items in the agreed remediation list and records whether each fix holds under the same conditions as the original test. Retests are scoped in writing like the original work, so the client knows which items are included and what the retest will produce. The output is a retest addendum that shows each item as closed, partially closed or still open, with the evidence used. The client decides whether the addendum goes to auditors or customers.
Maintain continuous review through a retainer
Where the client wants ongoing checks, a retainer can cover periodic configuration reviews of the tenant and sync path, re-validation after identity changes, and advice on new applications and consent requests. Scope, frequency and reporting for a retainer are set in a separate written agreement. The client gets updated findings and a change log it can share with internal audit. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, and a quote for any part of this work follows from the written scope.
