MFA and Conditional Access, made consistent and provable
Know which accounts are properly protected, and be able to prove it.
The accounts that should be protected are protected, and administrators hold their powers only while using them. You can show an insurer or auditor the test results rather than a promise.
- What you get
- Configured MFA and Conditional Access controls, sign-in test records and an exception register for the agreed accounts.
- How it starts
- A free scope call. The price is fixed in writing before anyone is given access.
- When it is done
- Approved policies are enforced after pilot checks, including intended access and recovery access. Remaining exceptions are documented and owned.
Illustrative sample · constructed example
One access rule, two sign-in outcomes.
Pilot policy · administrator access
Selected check
Does the pilot policy enforce the intended access condition?
PILOT / ADMINISTRATOR SIGN-IN
Emergency access has a separate test and restricted runbook. This pilot result does not close the exception register.
| Test case | Expected behavior | Sample review |
|---|---|---|
| Intended administrator | Allow sign-in under the agreed conditions. | Pilot observation |
| Outside policy conditions | Deny access when the enforced rule requires it. | Report-only observation |
| Emergency access | Test the separate recovery route and its runbook. | Separate test required |
| Exceptions | Name the exception owner and review conditions. | Owner review required |
Report-only observation is not enforcement. The sample does not certify the tenant or establish insurer acceptance.
Microsoft guidance: report-only policy evaluation- Evidence
- Report-only observation identifies a sign-in outside the intended condition.
- Decision
- Review before enforcement
- Next action
- Correct the policy or document the exception and test emergency access.
Illustrative sample. Evidence covers the tested control and identities; insurer or auditor acceptance is not guaranteed.
Open the complete illustrative document to inspect its fields and print a copy.
Open the sample documentWhy now
The work starts here.
Sign-in methods are mixed, administrators hold permanent rights, and there are policy exceptions nobody can explain.
Scope at a glance
- One Microsoft 365 tenant
- Sign-in path mapped at scoping
- Client owns end-user communications
If nobody acts
What waiting costs
The registration report shows who has enrolled a method. Whether that method is actually demanded at sign-in depends on a policy covering the account. So coverage read from the report can look higher than coverage in force.
An account whose MFA comes from Conditional Access shows as Disabled on the older per-user MFA page. That page can be read as a list of unprotected users when the protection is coming from somewhere else.
A device or job signing in with a stored password, like the printer that scans to email, fails at its next sign-in rather than when you switch the policy on. Tokens already issued stay valid until they expire.
Where no emergency account exists and is excluded from the policy set, a misfiring policy locks out the administrators who would otherwise reverse it. Getting back in then runs on Microsoft support timelines rather than yours.
Evidence assembled by hand describes the tenant on the day it was exported. The next questionnaire or renewal starts the same assembly again, and a policy changed in between shows up in neither.
Check your own environment
Sounds like you?
- Different users authenticate different ways and nobody can produce the full list
- Administrator roles are permanent because removing them was never safe to try
- Conditional Access has exceptions nobody can explain or date
- The emergency-access account either does not exist or nobody has tested it
- The last insurance questionnaire was answered from memory rather than the tenant
Save yourself the call
Not for you if
- MFA is already enforced for everyone and every exception is written down with an owner
- The deadline you are working to is the Microsoft phone-code retirement, which is its own job
- You need someone to fill in the questionnaire rather than change anything
The work
What is different when we hand over
The authentication method inventory is produced from the tenant: who signs in with what, including the accounts on nothing.
The agreed target methods are configured and rolled out group by group, with a pilot ring first.
Standing administrator roles are reduced to eligible assignments, and emergency access is created, excluded from the policy set, and tested.
A bounded Conditional Access policy set is deployed in report-only first, then enforced against the agreed populations.
Every exception is recorded with an owner, a reason, and a review date, and the evidence pack is assembled from the live tenant.
Acceptance
Checks before handover
Done when the approved user and administrator populations meet the agreed rules and every policy test passes or has a named exception.
Admin MFA is enforced and legacy authentication is blocked
The agreed Conditional Access set is deployed in its approved enforcement state
Emergency-access accounts exist, are excluded from the policy set, and alert when used
Named tests pass and the evidence packet is delivered
A fair question
Everyone here already has MFA. What is left to do?
Usually three things, and they are the three the questionnaire asks about. Whether the accounts that run in the background are covered as well as the people. Whether administrators hold their powers permanently or only while using them. And whether anyone can still sign in by a route that skips the rules entirely. "Everyone has MFA" is normally true and rarely the whole answer.
Price and calendar
Scope, price and project calendar
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- User and administrator population
- Number of existing Conditional Access policies
- Applications authenticating through Microsoft 365
- Named-user exceptions to carry
- Licensing tier available for the controls in scope
Scope & responsibilities
What is and is not included
The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.
Exclusions
- ADFS or third-party federation migration
- Service-account redesign
- Penetration testing
- Any guarantee that an insurer or auditor approves the environment
- Help desk and end-user support
What we need from you
- Distribute enrollment communications
- Handle routine enrollment questions from staff
- Approve the exception list and nominate an owner for each
- Provide administrative access and approve change windows
Change and rollback method
- Policies go in report-only before they are enforced, and enforcement is staged group by group with a pilot ring first.
- Rollback is the previous policy state, captured before the first change and re-appliable within one change window.
- Emergency-access accounts are confirmed excluded and alerting before any enforcement date is set.
What you keep at handover
- A System guide: the configuration as delivered, the checks that were run and the unresolved list
- The authentication method inventory, before and after
- The Conditional Access policy register, with the reason each policy exists
- The administrator role register and eligible-assignment configuration
- Test results against the agreed populations
- The exception register, with owners and review dates
- The evidence pack, assembled from the live tenant for an auditor or insurer to read
Access, acceptance and support arrangements
How you know the work is good
Judge it by what you can inspect.
The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.
- 01How a project runs
A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we work- 02What is checked
Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverables- 03What you keep
A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.
Next step
Start with a free scope call.
Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.
Price the access hardeningOr write to [email protected]