Do we need an assessment first?

Not necessarily. If you already know what needs fixing (MFA to enforce, conditional access to tighten, privileged accounts to review), we can scope directly to implementation. Our Cybersecurity Posture Assessment is available if you want a full baseline first, covering endpoints, network and backups as well as identity.

What do you do about service accounts and legacy authentication?

They are the two most common blind spots. Service accounts excluded from Conditional Access policies are brought into scope or isolated behind certificate-based authentication; legacy authentication protocols (IMAP, SMTP basic auth) are disabled tenant-wide after confirming no dependent integrations break. We then validate that the block is real.

What do you test after deployment?

Four points: MFA enforcement, confirmed active across every account and not just the ones we configured; Conditional Access policies, tested for exclusions and gaps that quietly defeat the rule; privileged accounts, reviewed for access that should have been revoked; and legacy authentication, confirmed blocked. Every gap comes with a specific action.

Does this become an ongoing engagement?

Only if you want it to. Implementation is a defined engagement that ends with the validation and the hand-off of the report. Recurring review of admin accounts, authentication checks and remediation tracking can then be handed off to our Managed Security Operations team, on a documented cadence.

Services · Implementation

Identity and access: enforcement validated, not assumed

MFA, conditional access and privileged accounts deployed on Entra ID, Okta or your identity provider, then tested: enabled is not the same as enforced.

Why this matters

Enabled isn't the same as enforced. Turning on MFA or standing up an identity provider isn't the finish line: it's easy to end up with policies that look right on paper but leave gaps in practice.

Partial MFA coverage

Legacy protocols or forgotten accounts can bypass MFA entirely, even when policy says it's required.

Stale privileged access

Admin rights granted for a one-time project rarely get revoked once the project ends.

Conditional access blind spots

A single misconfigured exclusion can quietly undo an otherwise strong policy.

No proof it's actually working

Without validation, "it's configured" and "it's enforced" are two different claims.

What sets this apart

We validate enforcement, not just configuration. We don't just deploy your identity and access solution: we go back and test that MFA, conditional access and privileged account controls are actually enforced, and hand you a specific action for anything that isn't.

MFA enforcement: confirmed active across every account, not just the ones we configured.
Conditional Access policies: tested for exclusions and gaps that quietly defeat the rule.
Privileged accounts: reviewed for access that should have been revoked.
Legacy authentication: confirmed blocked, not just deprecated on paper.

Sample validation findings

Illustrative examples; they do not describe a specific client.

High: a Conditional Access policy excludes six legacy service accounts from MFA. Action: bring service accounts into scope or isolate them behind certificate-based authentication.
High: three admin accounts retain Global Administrator rights from a completed migration project. Action: revoke standing access and require Privileged Identity Management (PIM) activation instead.
Medium: legacy authentication protocols (IMAP, SMTP basic auth) are still permitted for two mailboxes. Action: disable legacy auth tenant-wide and confirm no dependent integrations break.
Low: MFA enrollment is not enforced as a blocking step during new-hire onboarding. Action: add MFA enrollment as a mandatory step in the onboarding workflow.

What you get

MFA enforced on every account

Multi-factor authentication configured and confirmed active across all accounts, including service accounts and remote access, with enrollment built into new-hire onboarding.

Conditional Access policies without blind spots

Policies deployed on your identity provider, then tested for the exclusions and gaps that defeat the rule.

Privileged accounts under control

Standing access reviewed and revoked, with just-in-time activation through Privileged Identity Management where the platform supports it.

Legacy authentication blocked

Legacy protocols disabled tenant-wide, after checking dependent integrations.

A report with one action per gap

Every account, policy or protocol that fails validation gets a specific action.

Our approach

Assessment. Review of your existing identity and access infrastructure, policies and privileged accounts, to scope the engagement and its objectives.
Design. MFA, Conditional Access and privileged access management policies tailored to your identity provider and business needs.
Deployment. Configuration of the identity provider, access controls, multi-factor authentication and privileged access management, integrating with what you already use.
Validation and report. Test of the real enforcement of MFA, Conditional Access, privileged accounts and the legacy authentication block; hand-off of the report with a specific action for each gap.

Works with what you have

Built around your existing identity stack. Microsoft Entra ID, Okta, Conditional Access, multi-factor authentication, Privileged Identity Management: we integrate with the identity providers and controls you already use wherever possible, rather than forcing a migration.

After the engagement

An implementation engagement is a defined project. The monthly review of admin accounts and the authentication checks are part of the Managed Security Operations check framework. MFA on privileged accounts is also one of the most frequent findings in ISO 27001, CPCSC and CAN/DGSI 104 projects: this engagement delivers the control and its evidence.

Only the right people, only the right access.

Let's talk about your current identity setup and what needs to change.

Contact us

Frequently asked questions

Do we need an assessment first?: Not necessarily. If you already know what needs fixing (MFA to enforce, conditional access to tighten, privileged accounts to review), we can scope directly to implementation. Our Cybersecurity Posture Assessment is available if you want a full baseline first, covering endpoints, network and backups as well as identity.
Which identity providers do you work with?: Microsoft Entra ID, Okta and most major identity providers. We integrate with the providers and controls you already use (Conditional Access, multi-factor authentication, Privileged Identity Management) wherever possible, rather than forcing a migration; the goal is to validate that the controls are enforced, not to change platforms.
What do you do about service accounts and legacy authentication?: They are the two most common blind spots. Service accounts excluded from Conditional Access policies are brought into scope or isolated behind certificate-based authentication; legacy authentication protocols (IMAP, SMTP basic auth) are disabled tenant-wide after confirming no dependent integrations break. We then validate that the block is real.
What do you test after deployment?: Four points: MFA enforcement, confirmed active across every account and not just the ones we configured; Conditional Access policies, tested for exclusions and gaps that quietly defeat the rule; privileged accounts, reviewed for access that should have been revoked; and legacy authentication, confirmed blocked. Every gap comes with a specific action.
Does this become an ongoing engagement?: Only if you want it to. Implementation is a defined engagement that ends with the validation and the hand-off of the report. Recurring review of admin accounts, authentication checks and remediation tracking can then be handed off to our Managed Security Operations team, on a documented cadence.

Related pages

Let's talk about your compliance program.

Contact us