Germany
Endpoint management falls under co-determination in Germany. Projects that treat approval as a formality get halted after deployment. What is caught, how long it takes, and how to sequence around it.
By Alex Makey · 3 September 2026 · 7 min read
An international group rolls out Microsoft Intune across its subsidiaries. Everywhere else it goes smoothly. In Germany the project is halted after deployment, and nobody in the head office understands why.
The reason is the works council, and it is not a formality that can be handled at the end.
Under the Betriebsverfassungsgesetz — the German Works Constitution Act — a works council has co-determination rights over the introduction of technical systems that are capable of monitoring the behaviour or performance of employees. The relevant provision is §87(1) No. 6.
Two things about that wording matter more than they first appear.
“Capable of”, not “intended to”. It does not matter that you have no intention of monitoring anyone. What matters is whether the system could. Intune reports device compliance, application inventory and sign-in activity. It could. That is sufficient.
Co-determination, not consultation. This is not an obligation to inform the works council. It is an obligation to reach agreement with them. Without that agreement, the works council can require the system to be switched off — after it has been deployed, after the budget has been spent.
In practice, most of what an endpoint management project touches:
Microsoft Intune. Device enrolment, compliance policy, application inventory. Clearly in scope.
Conditional Access. Records sign-in location, device state and risk. In scope.
Microsoft Defender for Endpoint. Behavioural telemetry from the device. Firmly in scope, and usually the part the works council asks the most questions about.
Microsoft Purview audit and retention. Depends on configuration, but assume in scope.
Plain mailbox migration usually is not, because moving a mailbox does not create monitoring capability that did not exist. But if your migration project has an Intune workstream attached — and most do — the whole thing inherits the timeline of the slowest approval.
The output is a works agreement covering what is collected, who can see it, how long it is kept and what it may be used for. The questions that come up, nearly every time:
What data does the system collect from a device, precisely? Who inside the company can query it, and who outside — the group parent, the IT partner? Can the data be used in a disciplinary or performance context? What happens on a personal device under bring-your-own-device? How long is it retained, and what is deleted when someone leaves? How will employees be told what is running on their laptop?
These are reasonable questions. They are also questions with technical answers, which is why the engineering side needs to be in the room rather than waiting for a signature.
Longer than the technical work. That is the point that international teams find hardest to accept.
A works council meets on a schedule, may want external advice, and in a group with several German sites there may be more than one body to satisfy. Plan for months rather than weeks, and start the conversation at the same time as the technical design rather than after it.
We have seen the same rollout take three weeks in one country and a quarter in Germany, with identical technology.
The mistake is treating approval as a gate at the end. It works far better as a parallel track, and some of the technical work can proceed while it runs.
Can proceed: tenant configuration, Entra ID setup, licensing, building the policy set as a documented proposal, and piloting with a small volunteer group where that is agreed.
Should wait: broad enrolment, compliance enforcement, Conditional Access applied to real users, and anything that starts collecting telemetry from devices people are actually working on.
Structuring it this way means the day agreement is reached, you deploy rather than start designing. It also gives the works council something concrete to react to, which moves the conversation along faster than an abstract description.
A written description of exactly what each component collects. Not marketing material — the actual data points. A clear statement of who has access, including any external partner and what they can see. A proposed retention period with a reason for it. The answer to the bring-your-own-device question before it is asked. And a named person who owns the system afterwards.
Turning up without these is how a project loses a quarter.
Because the approval timeline should shape what you buy and when.
If Defender for Endpoint is going to sit unapproved for three months, buying it on a monthly term for those months and switching to an annual commitment afterwards costs less than committing for a year on the day the project starts. The reverse mistake — buying the full stack on a three-year term and then discovering half of it cannot be switched on until the summer — is one we have watched happen.
Commitment terms are set per subscription, not per tenant. Use that — and if you are choosing between CSP and an Enterprise Agreement for the estate, the works council timeline is one more argument for flexibility.
Germany is not difficult. It is specific. The rules are published, the process is predictable, and companies that operate there deal with it routinely.
What causes projects to fail is a head office that plans a rollout as though every country were the same, and a partner who does not mention the difference until it becomes a problem. If your partner has not raised the works council before you signed, ask what else they have not raised.
This is a practitioner’s summary based on our project experience, not legal advice. The specifics of any works agreement should be settled with counsel who practise German employment law.
One email a month, at most
Postmortems, timelines, licensing changes that cost people money. No newsletter cadence, no digest of other people’s news. If a month has nothing worth your time, you hear nothing.
Please enter a work email address.
Done. Unsubscribe by replying to any email; we will not argue.
Related questions
Yes, where a works council exists. Under §87(1) No. 6 of the Betriebsverfassungsgesetz the works council has co-determination rights over technical systems capable of monitoring employee behaviour or performance. Intune qualifies because it reports device compliance, application inventory and sign-in activity.
No. This is co-determination, not consultation. Agreement has to be reached. Without it, the works council can require the system to be switched off after deployment.
Microsoft Intune, Conditional Access, Microsoft Defender for Endpoint and, depending on configuration, Microsoft Purview audit and retention. Plain mailbox migration generally does not, but a migration project with an Intune workstream inherits the approval timeline.
Plan for months rather than weeks. A works council meets on a schedule, may seek external advice, and a group with several German sites may have more than one body to satisfy. The same rollout can take three weeks elsewhere and a quarter in Germany.
Tenant configuration, Entra ID setup, licensing, and building the policy set as a documented proposal. Broad enrolment, compliance enforcement and Conditional Access applied to real users should wait.
It should. If part of the stack cannot be switched on for months, a monthly commitment for that period costs less than committing for a year at project start. Commitment terms are set per subscription, not per tenant.
Working on one of these?
How many tenants, roughly how many users, and what is forcing the timing. You get back a sequence, an honest view of what will be slow, and a fixed price — usually within one business day.