New: CentriCall AI voice agents that answer, qualify, and book around the clock
Identity & access

Microsoft Entra ID and Azure AD consulting

Azure AD is now Microsoft Entra ID, and for most Microsoft estates it is the control plane everything else depends on — sign-in, MFA, app access, device trust. We assess how your tenant is configured today, fix the gaps that carry real risk, and leave your team able to run it without us.

Where tenants drift

Most tenants are not misconfigured on purpose. They are unfinished.

A tenant accretes. A conditional access policy added for one incident, a break-glass account nobody has tested, a sync set up for a migration that finished years ago, app registrations whose owner has left. None of it is wrong on the day it is made. Together it is an identity layer nobody can describe end to end — which is the state in which an audit, an acquisition, or an incident finds it. We start by writing down what is actually there.

Scope

What an Entra ID engagement covers

Tenant assessment

Authentication methods, conditional access coverage, privileged roles, guest access, and stale or over-permissioned accounts and app registrations — read from the tenant itself and reported as a ranked list, not a generic checklist.

Conditional access and MFA

Policies designed around who is signing in, from what, to what — with report-only mode first so nobody is locked out on the day they go live. Legacy authentication, break-glass accounts, and the exclusions that quietly accumulate are dealt with explicitly.

Hybrid identity and sync

Microsoft Entra Connect or Cloud Sync between on-premises Active Directory and the cloud, with password hash sync, pass-through, or federation chosen against your actual constraints rather than by default.

Application SSO

SAML and OpenID Connect single sign-on for your line-of-business and SaaS apps, app registration hygiene, and moving applications off bespoke credential stores onto the directory.

Privileged access and reviews

Just-in-time elevation through Privileged Identity Management, access reviews that someone is actually assigned to complete, and a role model that does not give every administrator standing global rights. Some of this needs Microsoft's premium licences, and we say which before you commit.

External identities

Partner and customer sign-in through Entra External ID — B2B collaboration for the people you work with, and customer-facing identity where a product needs its own sign-in.

Moving off AD FS and legacy sign-in

Federation was the right answer for a long time, and a lot of organisations are still running it. Moving to cloud authentication removes servers you have to patch and a single point of failure, but the cutover touches every sign-in, so the order matters.

  • AD FS to cloud authentication, using staged rollout to move groups of users across rather than flipping the whole domain
  • Relying-party trusts inventoried and migrated one application at a time, with the awkward ones identified before the cutover rather than during it
  • Legacy authentication protocols found, tracked to the apps and devices still using them, and retired with a rollback path
  • Running old and new in parallel until the new path has proven itself, rather than cutting over on a calendar date

Tooling

What we work in

Identity platform

  • Microsoft Entra ID
  • Conditional Access
  • Privileged Identity Management
  • Entra Connect
  • Cloud Sync
  • Entra External ID

Protocols and federation

  • SAML 2.0
  • OpenID Connect
  • OAuth 2.0
  • SCIM
  • AD FS

Automation and posture

  • Microsoft Graph API
  • PowerShell
  • Terraform (azuread provider)
  • Microsoft Defender for Identity
  • Azure Monitor

Questions

What teams ask before they start

Yes. Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023. It is the same service — same tenant, same users, same policies — under a new name, which is why both are still searched and why we use both. Entra is also the name of a wider product family, so you will see 'Entra ID' used when the directory specifically is meant.
Assess how your tenant is configured against how it should be, fix the gaps that carry real risk — usually conditional access coverage, privileged roles, and legacy authentication — migrate whatever is stuck on older infrastructure such as AD FS, and hand over documentation and runbooks so your own administrators can operate it. If you still need us in six months to explain your own tenant, the engagement did not work.
The assessment itself is typically one to two weeks, depending on tenant size and how many applications integrate with it. Remediation depends on what the assessment finds: tightening conditional access in report-only mode is quick, while retiring AD FS across a large application estate is a multi-month programme because the constraint is the applications, not the directory.
Not if they are rolled out properly. Every policy goes live in report-only mode first so you can see exactly who it would have blocked, break-glass accounts are excluded and tested before anything is enforced, and each change has a documented rollback. Lockouts almost always come from enforcing a policy that was never observed.
Conditional access requires P1; Privileged Identity Management and the more advanced risk-based policies require P2, and some governance features are licensed separately again. Licensing changes, so we check current Microsoft terms against what you actually need and tell you early — some of the highest-value fixes need no licence beyond what you already own.
Yes, and identity usually goes first — until the directory is synchronised and working, every workload you move inherits the problem. If the engagement is mostly landing zones and workload migration, the Azure consulting page is the better starting point; this one is for when identity is the subject.