MFA is introduced, that was the first big step. Still, you have the feeling that the security of your Microsoft 365 tenant continues to sit on thin ice: nobody knows exactly who has which accesses, Conditional Access is a mystery, and whether the notebooks of the field-sales team are compliant, you can only hope. Zero Trust is not a product you buy. We build the baseline with you in three realistic steps, without your employees going on strike.
Do you have this situation?
- MFA runs, but nobody can say off the top of their head whether really all accounts are protected. There is suspicion of a few exceptions from the rollout phase that nobody cleaned up cleanly — service accounts, emergency logins, the one managing director for whom MFA was “too annoying”.
- Conditional Access exists as a term, but whoever looks at the policies in the tenant finds a wild mix: two policies from the rollout service provider, one self-created with the name “Test”, and a Microsoft standard policy that nobody consciously activated.
- Notebooks in field sales are not systematically managed. Whether their hard disks are encrypted, whether the operating system is up to date, whether Defender is active — that’s trust, not evidence.
- External persons (tax adviser, auditor, suppliers, freelancers) have received guest access to SharePoint or Teams over the years. Whether these guests still need to be active, nobody has checked since the first invitation.
- The cyber insurer or a customer demands proof of access governance — and you have the feeling that the honest answer “we’re working on it” would sound rather weak.
Why solve this now instead of postponing
Zero Trust is not a buzzword but a pragmatic answer to a changed world: users work from anywhere, devices are managed to varying degrees, identities are the actual gate to the company. Whoever continues to anchor security solely to network boundaries (“firewall at the site”) is playing a game that worked ten years ago. Today most attacks come via compromised identities, not via breached firewalls.
The uncomfortable news: introducing a complete Zero Trust architecture in a mid-market company is not a three-week project. The good news: the baseline — the most important 70 to 80 percent of the effect — is doable, and it’s doable without a big-bang migration.
Typical triggers that are now due:
- Cyber insurer demands proof on MFA coverage, Conditional Access and device compliance.
- NIS-2 hits you directly or as a supplier — identity governance and access control are mandatory topics.
- A customer demands a supplier security questionnaire — and the questions are not superficial.
- A phishing incident has just shown how far a single compromised account gets.
- Audit note on permissions, logging or guest governance is on the table.
How it would look at your company
We deliberately don’t tackle this as a big-bang, but in three steps — identity, devices, governance. Per step a test phase with a small group, then rollout. Whoever enforces everything at once locks out half the workforce on Monday morning, and trust is then gone for months.
Step 1 — Identity inventory and MFA gap-closure
Before we build Conditional Access, we do an honest assessment: which accounts exist in the tenant, which are active, which are privileged, where is MFA really missing? We also look at the uncomfortable areas: former employees whose account is “by mistake” still active; service accounts with old passwords; management accounts that were kept out of the MFA obligation as a “special exception”.
Delivery: an identity overview in which every account has a status (active/inactive, MFA status, privileged role yes/no, last login). Plus a prioritized gap-closure plan. This step alone discovers in most mid-market tenants between 5 and 20 accounts that nobody needs anymore — or that should long since have been protected.
Stack hints: Entra ID Sign-in Logs, Audit Logs, Microsoft Graph for identity inventory, Entra ID PIM for privileged roles.
Step 2 — Build Conditional Access pragmatically
This is where the biggest lever lies and at the same time the biggest risk. We build a Conditional Access baseline that answers the following core questions:
- Must all users sign in with MFA — especially privileged accounts?
- Are sign-ins from abroad handled differently when the company operates purely in DACH?
- Are outdated authentication protocols (Legacy Auth, IMAP, POP) blocked?
- Are sign-ins from non-managed devices handled differently than from company devices?
- Is there a break-glass account for the emergency that is deliberately exempted from Conditional Access, and is its password securely stored?
We implement this step by step: first report-only mode, so we see what a policy would block without actually blocking. Then a trial with IT and volunteer users. Only then broad rollout. Delivery: a documented set of 5 to 10 policies that your tenant carries — with clearly named exceptions for special cases (e.g. CAD workstation without an MFA-capable device, if that really can’t be done otherwise).
Stack hints: Conditional Access (incl. report-only mode), Authentication Strengths, Continuous Access Evaluation, break-glass account pattern.
Step 3 — Device baseline with Intune
Identity alone isn’t enough. If a notebook is compromised, the best MFA doesn’t help. That’s why we build a device baseline: company notebooks are enrolled in Intune, get a compliance policy (BitLocker on, Defender active, OS current), and Conditional Access is extended so that critical applications are only accessible from devices marked as compliant.
For BYOD (employee’s own smartphone also used for the mailbox) we deliberately forgo full management. Instead, App Protection: company data in the Outlook app is protected against copy/paste into private apps, without Nexaro or IT accessing private photos. That’s acceptable for employees and still protects the relevant data path.
Delivery: all company notebooks in Intune, compliance policy active, BYOD smartphones with App Protection. Plus an onboarding path for new devices (Autopilot), so this doesn’t fall apart again.
Stack hints: Microsoft Intune, Compliance Policies, App Protection Policies, Autopilot, Defender for Endpoint onboarding.
Step 4 — Guest governance and privileged access
External persons who have had access for years are a frequently overlooked risk. We build a review rhythm with you: all guest accounts are confirmed once per quarter by the inviting person — whoever isn’t confirmed is automatically deactivated. Plus access reviews for internal privileged roles: who is Global Administrator, who is SharePoint Administrator, is this still justified?
Delivery: a quarterly rhythm for access reviews, set up in the tenant, with clear responsibilities. Plus a configured Privileged Identity Management for the top roles — so that, for example, Global Admin rights are not permanently assigned but activated on demand for a few hours.
Stack hints: Entra ID Access Reviews, Entra ID PIM, Entitlement Management for guest onboarding.
Step 5 — Employee communication and understanding
This is the step where most Zero Trust projects fail — not on the technology. We help you communicate internally what changes for users, why, and when. A short email to everyone is not enough. We propose a small package: a one-pager for management (why are we doing this at all), a one-pager for users (what changes concretely, what do I have to do), a Q&A list for the most frequent questions, and a clear contact person for the rollout phase.
Delivery: communication material in your language, approved by management, rolled out one week before the respective policy activation.
What you should look out for along the way
- Ask for the rollback plan before any Conditional Access policy is enforced. Whoever has no quick answer to “What happens if the policy suddenly locks out half the company?” has no plan. Break-glass account and report-only mode are mandatory.
- Zero Trust is not a product, but an architectural stance. Whoever wants to sell you Zero Trust as a bought package hasn’t understood it. It is the sum of identity, device and access decisions, and it happens in steps.
- Don’t be impressed by “risk-based authentication” if the basics aren’t standing. Conditional Access with risk signals is powerful, but it needs a clean identity basis. Whoever jumps to the third step at the first is building on sand.
- Clarify with management BEFORE the rollout that short-term inconveniences will come. If management caves in the first complaint storm and demands exceptions for itself, the project is politically dead. Management as a visible role model is more important here than any policy.
- Watch out with templates and “best practice packages”. The Microsoft templates for Conditional Access are a good starting point, but they rarely fit without adaptation. Whoever rolls out the Microsoft template 1:1 most likely blocks something that is business-critical at your company.
What realistically changes afterwards
- To the question “Does every employee have MFA?” you can answer in a minute with a documented list — including the conscious exceptions with justification.
- Conditional Access is no longer a mystery but a documented set of policies that an external auditor can follow.
- Company notebooks are no longer a trust topic but a compliance status. A non-compliant notebook gets no access to SharePoint with the engineering data.
- Guest accounts are reviewed quarterly, instead of existing silently over years.
- When the cyber insurer or a customer asks about access governance, you have documents, not platitudes.
What you contribute
- Administrative access to Entra ID, Conditional Access and Intune (time-bounded, ideally via PIM).
- One person at your company who carries the project, accompanies communication to the workforce and is reachable during the rollout phase.
- Willingness of management to visibly carry the topic — including own MFA, own compliance requirements on the management notebook, own guest reviews.
- About 15 to 30 hours of stakeholder time spread across several months, plus the purely technical implementation appointments.
Risks and when it doesn’t fit
- If the tenant has just been freshly migrated and is still unstable — then first stability, then Zero Trust. A Conditional Access policy on a half-finished migration is a double problem.
- If management doesn’t carry the topic and demands exceptions for itself, the project fails politically. We then say in the initial conversation: first clarify the stance, then the technology.
- If you currently also have a tenant cleanup need, we tackle that first or in parallel — Zero Trust on a cleaned-up tenant is considerably more relaxed than on a garbage heap.
- If your license inventory doesn’t include Business Premium or E3 features, Conditional Access and Intune are missing. We clarify that in the initial conversation — sometimes a license adjustment is the first step.
How the conversation starts
- 30 minutes initial conversation, free of charge, by video or phone.
- What we clarify: current MFA state, existing Conditional Access policies (or absence thereof), license inventory, device landscape (predominantly company notebooks or a mix), current pressure (insurer, NIS-2, incident).
- Optionally useful in advance: a screenshot of the license overview from the Microsoft 365 Admin Center, rough headcount, information on whether Intune is already in use.
Frequently asked questions
Do we need Microsoft E5 to introduce Zero Trust? No. Business Premium or E3 are enough for a solid baseline — MFA, Conditional Access, Intune and Defender for Endpoint are included there. E5 brings additional features like risk-based authentication and Defender for Identity, which make sense in larger environments. In the Mittelstand, Business Premium is sufficient for most scenarios.
How long does the baseline introduction take? Realistically 3 to 6 months from identity inventory to a stable Conditional Access configuration with device compliance, depending on size and starting state. That’s not a three-week project — and it shouldn’t be, if the workforce is to be able to keep working at the end.
Will our employees accept it? If the communication runs well and management visibly comes along: yes. Conditional Access is hardly noticeable in daily work for most users — they sign in once in the morning with MFA, then it runs. It only becomes noticeable in special cases (access from an unknown device, travel outside DACH), and exactly there it should be noticeable.
What if we need emergency access and MFA doesn’t work? That’s what the break-glass account is for — a deliberately exempted emergency account with a very long password that sits in a safe. Nobody uses it in daily work, but it exists for the day on which the MFA provider, the internet or Conditional Access itself causes problems. Setting up the break-glass account is mandatory, not a nice-to-have.
Related
- Service: Security & Governance
- Use Case: How do we really test restore and recovery, instead of just letting backups run?
- Use Case: How do we clean up a historically grown Microsoft 365 tenant?
- Knowledge (German): GDPR-compliant cloud migration in 6 steps