One account.
Everything gone?
Not necessarily.
NIS2 mandates ten risk measures. With Managed Red Tenant and Dark Tenant, we support their technical implementation — for a significantly reduced attack risk and the certainty of being operational again within hours when it matters.
What made the Stryker attack on March 11, 2026 remarkable wasn't the number of affected devices — though 80,000 devices across 79 countries is a striking figure — but the banality of the method: no exploit, no zero-day, no sophisticated attack on obscure infrastructure components. A single compromised Intune admin account was enough, and from the outside the attack looked like normal operations — because technically it was, just executed by someone else. What exactly happened is covered in the Stryker attack blog post.
Most enterprise infrastructures are built in a way that makes this kind of damage possible — not because anyone was negligent, but because privileged accounts with broad permissions have been considered practical for years: one account with access to everything saves time in daily operations, and time is notoriously the one thing even scarcer than budget in IT departments. NIS2 Article 21 draws the consequences from this practice: privileged identities must be isolated in a way that prevents their compromise from taking down the entire infrastructure, and those who still get hit must be able to operate again within hours.
What NIS2 is and who it applies to is covered here. This page is about supporting the technical implementation of the risk measures with Managed Red Tenant and Managed Dark Tenant.
Managed Red Tenant: so a compromised account doesn't become a master key
The attack pattern that worked in the Stryker incident isn't new: attackers compromise an account that gives them access to privileged systems, move laterally from there to the rest of the infrastructure, and cause the damage their permissions allow. It works so reliably because most organizations have no structural separation between standard work environments and the administrative access that would be sufficient to take over the entire infrastructure.
Managed Red Tenant breaks this pattern by moving administrative identities and their associated endpoints into a fully separated Microsoft tenant — with dedicated Entra ID accounts, dedicated hardened devices, and no network connection to the production environment that an attacker could use for lateral movement. Anyone trying to move from a compromised standard workstation toward critical systems runs into a boundary that didn't exist before.
Managed Red Tenant
Managed Dark Tenant: the prepared environment for the scenario that shouldn't happen but might
After a large-scale ransomware attack, the problems a company faces fall into two categories: the technical ones, which are solvable — if not quickly — and the organizational ones, where no one defined in advance who does what in a crisis, in what order decisions get made, or what communication can even be trusted when the company's own infrastructure is no longer reliable. Coveware puts the average downtime after a ransomware attack at 24 days, and incident experience shows the delay is rarely caused by a lack of technical resources — it's caused by having to invent, under extreme pressure, processes that were never needed during normal operations.
Managed Dark Tenant is a pre-provisioned, fully isolated Microsoft environment that gets activated in a crisis via a 24/7 hotline and gives the response team operational communication, Windows 365 workstations, and an AD recovery pipeline within hours — all built on Infrastructure as Code, all defined and tested before it's needed. The underlying architecture principle is called Minimum Viable Company: communication first, then critical documents, then core applications — in an order that's defined in advance and regularly tested through Fire Drills.
Managed Dark TenantWe support the technical implementation
| Risk Measures | GK Services | NIS2 | CSOC | APT Response | Preventive Services | Managed Red Tenant | Managed Dark Tenant | Data Security | Workplace / Azure |
|---|---|---|---|---|---|---|---|---|
| Risk Analysis and Information System Security | 21.2 a) | |||||||
| Incident Handling | 21.2 b) | NEU | NEU | |||||
| Business Continuity | 21.2 c) | NEU | ||||||
| Supply Chain Security | 21.2 d) | NEU | ||||||
| Security in Network and Information Systems | 21.2 e) | |||||||
| Effectiveness of Cybersecurity Risk Management Measures | 21.2 f) | NEU | NEU | |||||
| Basic Computer Hygiene Practices and Cybersecurity Training | 21.2 g) | |||||||
| Cryptography | 21.2 h) | |||||||
| Human Resources Security, Access Control Policies and Asset Management | 21.2 i) | NEU | ||||||
| Multifactor Authentication or Secured Communication | 21.2 j) | NEU |
Two services, one answer to NIS2 Article 21
Managed Red Tenant
Privileged identities and endpoints in a fully separated Microsoft tenant with no network connection to the production environment. No lateral movement, no compromised standard account that becomes a master key to the entire infrastructure.
Managed Dark Tenant
A pre-provisioned, isolated Microsoft environment activated in a crisis via a 24/7 hotline. Communication, Windows 365 workstations, and an AD recovery pipeline are defined and tested before they are needed.
MRT & MDT together
Red Tenant reduces the likelihood that an attack takes down the entire infrastructure. Dark Tenant reduces downtime if it does. NIS2 aside: both together make sense regardless of regulatory pressure.
Further reading
Are you ready for NIS2?
The new NIS2 directive places a whole range of requirements on companies and their cyber security - from minimum measures ...
