---
title: "How do we pragmatically introduce a Zero-Trust baseline in the Mittelstand?"
description: "Zero Trust is not a product. We build the baseline in five realistic steps in your Microsoft 365 tenant — without overwhelming your workforce."
canonical: "https://demo22.berndt.to/en/use-cases/zero-trust-baseline/"
lang: en
schema_type: Article
---
# How do we pragmatically introduce a Zero-Trust baseline in the Mittelstand?

Zero Trust is not a product. We build the baseline in five realistic steps in your Microsoft 365 tenant — without overwhelming your workforce.

## The short version

- **What:** Building a Zero Trust baseline in Microsoft 365 in five steps: identity inventory, Conditional Access, device baseline, guest governance, communication.
- **Who it's for:** Mid-market companies on Microsoft 365 that need to demonstrate access governance — to insurers, customers or under NIS-2.
- **Timeline:** Realistically 3 to 6 months, depending on the size and starting state of your tenant.
- **Outcome:** Documented Conditional Access policies, managed devices in Intune, quarterly access reviews — provable instead of a matter of trust.

A good fit if:

- MFA is running, but Conditional Access and device compliance are patchwork or missing entirely.
- Your cyber insurer, customers or NIS-2 demand proof of access governance.
- External guests have had unreviewed access to SharePoint or Teams for years.

MFA is in place — that was the first big step. Still, you have the nagging feeling that the security of your Microsoft 365 tenant remains on thin ice: nobody knows exactly who has access to what, Conditional Access is a mystery, and whether the field-sales notebooks are compliant is anyone's guess. Zero Trust is not a product you buy. We build the baseline with you in five realistic steps — without your employees going on strike.

## Does this sound familiar?

- MFA is running, but nobody can say off the top of their head whether every account is actually protected. There's a suspicion that a few exceptions from the rollout phase were never properly cleaned up — service accounts, emergency logins, the one managing director who found MFA "too annoying".
- Conditional Access exists as a term, but anyone who looks at the policies in the tenant finds a wild mix: two policies from the rollout provider, one self-created policy named "Test", and a Microsoft default policy that nobody consciously enabled.
- Field-sales notebooks are not systematically managed. Whether their disks are encrypted, the operating system is up to date, Defender is active — that's a matter of trust, not evidence.
- External people (tax adviser, auditor, suppliers, freelancers) have accumulated guest access to SharePoint or Teams over the years. Nobody has checked since the first invitation whether those guests still need to be active.
- Your cyber insurer or a customer demands proof of access governance — and you sense that the honest answer, "we're working on it", would sound rather weak.

## Why now — and not later

Zero Trust is not a buzzword but a pragmatic answer to a changed world: people work from anywhere, devices are managed to varying degrees, and identities are the real gateway into the company. Anchoring security solely to network boundaries ("the firewall at the office") means playing a game that stopped working ten years ago. Today, most attacks come through compromised identities, not 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 achievable, and it's achievable without a big-bang migration.

Typical triggers that put this on the agenda now:

- **Your cyber insurer demands proof** of MFA coverage, Conditional Access and device compliance.
- **NIS-2 affects you directly or as a supplier** — identity governance and access control are mandatory topics.
- **A customer sends a supplier security questionnaire** — and the questions are not superficial.
- **A phishing incident has just shown** how far a single compromised account can get.
- **An audit finding** on permissions, logging or guest governance is on the table.

## What this would look like at your company

We deliberately don't tackle this as a big bang, but along three fields of action — identity, devices, governance — implemented in five steps. Each step gets a test phase with a small group, then the rollout. Switch everything on at once and you lock out half the workforce on Monday morning — and trust is gone for months.

### Step 1 — Identity inventory and closing the MFA gaps

Before we build Conditional Access, we take an honest inventory: which accounts exist in the tenant, which are active, which are privileged, where is MFA actually missing? We also look into the uncomfortable corners: former employees whose accounts are "accidentally" still active; service accounts with ancient passwords; management accounts that were kept out of the MFA requirement as a "special exception".

Deliverable: an identity overview in which every account has a status (active/inactive, MFA status, privileged role yes/no, last sign-in). Plus a prioritized remediation plan. In our experience, tenants that have grown over the years regularly contain accounts nobody needs anymore — or accounts that should have been protected long ago.

Stack hints: Entra ID Sign-in Logs, Audit Logs, Microsoft Graph for the identity inventory, Entra ID PIM for privileged roles.

### Step 2 — Build Conditional Access pragmatically

This is where the biggest lever sits — and the biggest risk. We build a Conditional Access baseline that answers the following core questions:

- Do all users have to sign in with MFA — including privileged accounts, those especially?
- Are sign-ins from abroad handled differently when the company operates purely within DACH?
- Are outdated authentication protocols (legacy auth, IMAP, POP) blocked?
- Are sign-ins from unmanaged devices treated differently than sign-ins from company devices?
- Is there a break-glass account for emergencies, deliberately exempted from Conditional Access, and is its password stored securely?

We implement this step by step: first report-only mode, so we can see what a policy would block without actually blocking anything. Then a trial run with IT and volunteer users. Only then the broad rollout. Deliverable: a documented set of 5 to 10 policies your tenant can carry — with clearly named exceptions for special cases (e.g. a CAD workstation without an MFA-capable device, if there is genuinely no other way).

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 won't help. That's why we build a device baseline: company notebooks are enrolled in Intune, receive a compliance policy (BitLocker on, Defender active, OS current), and Conditional Access is extended so that critical applications are only reachable from devices marked as compliant.

For BYOD (an employee's personal smartphone that is 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 gaining any access to private photos. That's acceptable to employees and still protects the data path that matters.

Deliverable: 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 people who have had access for years are a frequently overlooked risk. We set up a review rhythm with you: every guest account is confirmed once a quarter by the person who invited them — anyone not confirmed is automatically deactivated. Plus access reviews for internal privileged roles: who is Global Administrator, who is SharePoint Administrator, and is that still justified?

Deliverable: a quarterly access-review rhythm, set up in the tenant, with clear responsibilities. Plus Privileged Identity Management configured for the top roles — so that Global Admin rights, for example, 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 buy-in

This is the step where most Zero Trust projects fail — not the technology. We help you communicate internally what changes for users, why, and when. A short all-staff email 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 need to do), a Q&A list for the most common questions, and a clearly named contact person for the rollout phase.

Deliverable: communication material in your language, approved by management, rolled out one week before each policy goes live.

## What to watch out for

- **Ask for the rollback plan before any Conditional Access policy goes live.** Anyone without a quick answer to "What happens if the policy suddenly locks out half the company?" has no plan. A break-glass account and report-only mode are mandatory.
- **Zero Trust is not a product; it's an architectural stance.** Anyone trying to sell you Zero Trust as an off-the-shelf package hasn't understood it. It's the sum of identity, device and access decisions, and it happens in steps.
- **Don't be dazzled by "risk-based authentication" if the basics aren't in place.** Conditional Access with risk signals is powerful, but it needs a clean identity foundation. Jumping from step one straight to step three means building on sand.
- **Get management to acknowledge, BEFORE the rollout, that there will be short-term inconvenience.** If management caves at the first storm of complaints and demands exceptions for itself, the project is politically dead. Management leading by visible example matters more here than any policy.
- **Be careful with templates and "best-practice packages".** Microsoft's Conditional Access templates are a good starting point, but they rarely fit without adaptation. Roll out a Microsoft template 1:1 and you will very likely block something that is business-critical for you.

## What realistically changes afterwards

- "Does every employee have MFA?" — you can answer that within a minute with a documented list, including the deliberate exceptions and their 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 matter of trust but a compliance status. A non-compliant notebook gets no access to the SharePoint site holding your engineering data.
- Guest accounts are reviewed quarterly instead of quietly living on for years.
- When your 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-limited, ideally via PIM).
- One person on your side who owns the project internally, supports communication to the workforce and is reachable during the rollout phase.
- Willingness of management to visibly back the topic — including their own MFA, their own compliance requirements on the management notebook, their own guest reviews.
- Roughly 15 to 30 hours of stakeholder time spread across several months, plus the purely technical implementation sessions.

## Risks and when it's not a fit

- If the tenant has just been migrated and is still unstable — then stability first, Zero Trust second. A Conditional Access policy on top of a half-finished migration is a double problem.
- If management doesn't back the topic and demands exceptions for itself, the project fails politically. We'd rather say so in the initial conversation: clarify the stance first, then the technology.
- If your tenant also needs a cleanup, we tackle that first or in parallel — Zero Trust on a tidy tenant is far more relaxed than on a garbage heap.
- If your licensing 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

- A 30-minute initial conversation, free of charge, by video or phone.
- What we clarify: your current MFA state, existing Conditional Access policies (or the lack of them), licensing, device landscape (mostly company notebooks or a mix), and the current pressure (insurer, NIS-2, incident).
- Optionally useful in advance: a screenshot of the license overview from the Microsoft 365 admin center, a rough headcount, and whether Intune is already in use.

[Book an initial conversation](/en/contact)

## Frequently asked questions

**Do we need Microsoft E5 to introduce Zero Trust?**
No. Business Premium or E3 is enough for a solid baseline — MFA, Conditional Access, Intune and Defender for Endpoint are included there. E5 adds 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 introducing the baseline take?**
Realistically 3 to 6 months from identity inventory to a stable Conditional Access configuration with device compliance, depending on the size and starting state of your tenant. That's not a three-week project — and it shouldn't be, if the workforce is supposed to still be able to work at the end.

**Will our employees accept it?**
If the communication is done well and management visibly leads the way: yes. In day-to-day work, Conditional Access is barely noticeable for most users — they sign in once in the morning with MFA, and that's it. It only becomes noticeable in the special cases (access from an unknown device, travel outside DACH), and that's exactly where it should be noticeable.

**What if we need emergency access and MFA isn't working?**
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 when 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](/en/services/security-governance)
- Use Case: [How do we really test restore and recovery, instead of just letting backups run?](/en/use-cases/backup-drill)
- Use Case: [How do we clean up a historically grown Microsoft 365 tenant?](/en/use-cases/m365-tenant-cleanup)
- Knowledge (German): [GDPR-compliant cloud migration in 6 steps](/de/wissen/dsgvo-konforme-cloud-migration-6-schritte)