Identity review
Review administrator roles, sign-in settings and dependencies.
Findings and a staged policy plan with justified exceptions.
Cybersecurity · Identity
Microsoft Entra ID migration and setup, built around Zero Trust
Most breaches now start with identity: a phished password, an MFA prompt approved by mistake, an admin account nobody remembers creating. We set up and tidy Microsoft Entra ID remotely, so every sign-in is checked against who the user is, what device they're on and what they're trying to reach.
/ Fit check
Best for
Microsoft 365 businesses moving off on-premises Active Directory, or tidying a tenant that grew without a plan
Not for
Teams that want MFA forced on everyone by Friday with no pilot
Deliverables
Conditional Access design, admin role review, identity scorecard and runbooks
/ Direct answer
What does a Microsoft Entra ID migration and setup involve?
Microsoft Entra ID migration and setup covers synchronised or cloud-only identities, MFA methods, Conditional Access policies, admin roles, guest access, app registrations and sign-in monitoring. BPro Technologies reviews application and device dependencies before planning the changes. We use report-only evaluation where supported, followed by pilot testing before wider enforcement.
- Report-only testing before enforcement
- Admin roles cut to what's needed
- An identity scorecard tracked monthly
/ Scope your engagement
Stage identity changes before extending them to everyone.
Ongoing tenant administration, a security review and an Intune rollout have different deliverables. We confirm licences, devices and change authority before work starts.
Migration or configuration
Scope hybrid identity, MFA or Conditional Access changes.
Pilot, recovery checks and approved rollout groups.
Ongoing administration
Handle agreed access and identity requests after the rollout.
Approval rules, policy ownership and review records.
Example Conditional Access rollout recordView an illustrative deliverable
This example illustrates the record format. It is not a client result or a service-level commitment. Your proposal lists the deliverables and responsible people.
| Stage | Check | Acceptance |
|---|---|---|
| Prepare | Licences, admin roles, emergency access and application dependencies | Authorised owner approves the pilot and recovery procedure |
| Pilot | Review policy results and representative sign-in scenarios | Confirm intended access works and unexpected blocks are resolved |
| Expand | Roll out in approved groups and monitor exceptions | Record policy owner, test evidence and review date |
What to bring to the first conversation
Tenant, hybrid identity dependencies, sign-in concerns, licences and the applications affected by a policy change.
/ 01
What does Zero Trust mean for a Microsoft 365 business?
Zero Trust avoids granting access solely because a user or device is on the company network. Apply least privilege and explicit access policies to the resources being protected. Conditional Access can use identity, device, location and risk signals where configured and licensed; it does not mean every request receives every available check.
Choose controls around the applications, users and devices involved. Microsoft Entra Conditional Access requires an eligible P1 entitlement; user and sign-in risk policies require P2 capabilities. Related products, such as Intune, have their own licensing requirements. Confirm the exact subscription and affected users before rollout.
/ 02
How do you roll out Conditional Access without locking people out?
Start policies in report-only mode to review their likely effects before enforcement. Maintain separately governed emergency access accounts, excluded from Conditional Access policies that block or restrict sign-in, and monitor their use. Report-only policies do not require that exclusion. Pilot enforcement, test recovery and expand in stages to reduce lockout risk; policy dependencies and access still need validation.
01
Emergency access accounts
Two cloud-only admin accounts with separately secured phishing-resistant credentials and sign-in alerts. Exclude them from Conditional Access policies that block or restrict sign-in; report-only policies need no exclusion.
02
Baseline policies in report-only
Require MFA for all users, block legacy authentication, require phishing-resistant MFA for admin roles.
03
Read the sign-in logs
One to two weeks of real data shows which users, devices and apps would have failed.
04
Pilot enforcement
IT and a volunteer group first. Anything that breaks gets fixed before it reaches everyone.
05
Staged rollout
Team by team, with instructions sent before each stage.
06
Exclusions with owners
Every exception has a reason, an owner and an expiry date, and gets reviewed each quarter.
/ 03
What does a good MFA rollout plan look like?
Start with administrators, then high-risk roles such as finance, with a registration window before each enforcement stage. Prefer supported phishing-resistant methods such as passkeys or FIDO2 security keys. Authenticator push with number matching reduces accidental approval but is not phishing-resistant. Test recovery, govern emergency access separately and brief users before enforcement. Adapt the phased plan to Google Workspace's supported 2-Step Verification methods and enforcement controls.
01
Admins first
Every privileged account on a phishing-resistant method before anything else changes.
02
High-risk roles
Finance, HR and executives, who are the usual targets of account takeover.
03
Registration window
Staff register their method during a set period, with instructions and help on hand.
04
Enforce in stages
Team by team, so problems surface in small groups rather than all at once.
05
Close the gaps
Chase unregistered accounts by name and review exceptions every quarter.
/ 04
What is an identity scorecard?
An identity scorecard is a short, repeatable measurement of how well your accounts are protected, reviewed monthly so you can see the trend. It tracks MFA coverage, phishing-resistant method adoption, the number of Global Administrators, stale accounts, guests with no sponsor and legacy sign-in attempts.
The review checks administrative privileges, accounts belonging to former staff and guest access from completed projects. Each finding needs an owner and a decision: retain with a documented purpose, reduce access or disable the account after checking dependencies.
Illustrative scorecard · fictional tenant
| Measure | Target | Example first review |
|---|---|---|
| Users with MFA registered | 100% | 97% (6 users pending) |
| Global Administrators | Fewer than five | 7 |
| Admins on phishing-resistant MFA | 100% | 40% |
| Legacy authentication sign-ins | 0 | 12 in 30 days |
| Enabled accounts inactive 90+ days | 0 | 14 |
| Guests with no sponsor | 0 | 31 |
/ 05
What access is needed for Entra ID setup?
We identify the administrative roles, tenant access, application owners and any synchronisation servers needed for the work. Access is limited to the tasks being carried out. Users receive instructions for authentication-method registration, and any work involving local systems is planned with the person responsible for them.
/ 06
How do you migrate from on-premises Active Directory to Entra ID?
Usually in two moves. First, synchronise on-premises accounts to Entra ID with Entra Connect Sync or Cloud Sync, so people use one identity everywhere. Then, over time, move devices to Entra join through Intune and retire the dependencies on local domain controllers. Going cloud-only in one jump works for small environments but is risky where old applications still authenticate against AD.
Clean up Active Directory before you sync it. Stale accounts, duplicate attributes and sign-in names on unverified domains all travel into the cloud if you let them, and they're easier to fix before than after.
Frequently Asked Questions
Yes. Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023. The product and your existing configuration didn't change, only the name.
Microsoft Entra Conditional Access requires an eligible P1 entitlement, included with Microsoft 365 Business Premium. User and sign-in risk policies require Entra ID Protection P2 capabilities. Check the exact subscription, affected users and any related Intune or other product licences rather than relying on an E3 or E5 label alone.
Emergency access accounts provide a recovery route if normal administrator sign-in fails. Maintain two cloud-only accounts with separately secured phishing-resistant credentials, monitor their use and test access regularly. Exclude them from Conditional Access policies that block or restrict sign-in; report-only policies do not need that exclusion. These arrangements reduce lockout risk but still depend on working credentials and service availability.
It depends on the migration, existing registrations and authentication methods being introduced. We check which users need to register again, explain the steps and test the recovery process before rollout.
Yes. We review guest accounts, identify a responsible sponsor and check whether access is still needed. Access is removed when collaboration ends, with retention and application dependencies checked before account deletion.
Yes. The same Zero Trust principles apply in Google Workspace: enforced 2-Step Verification, separate super admin accounts, context-aware access where your edition supports it, and regular review of third-party app access. This page focuses on Entra ID because it's where most Microsoft 365 businesses start.
Timing depends on the tenant, application dependencies, identity model and testing required. The project plan includes time to observe representative sign-ins, resolve unexpected policy effects and confirm recovery arrangements before wider rollout.
/ Next step
Review your Entra ID requirements
Tenant, hybrid identity dependencies, sign-in concerns, licences and the applications affected by a policy change.