MRISMythos-Resistant Information Security
DEEN

MRIS.bd 2.0, user-defined modules for IT-Grundschutz. As of 19 September 2026

The 13 MHC as a module family for IT-Grundschutz

One process module for the entire information domain and four system modules for identity and access systems, backup, execution platforms and AI agents. 23 requirements with implementation guidance, a cross-reference table and a machine-readable edition, ready for modelling and the IT-Grundschutz check.

Download the package (ZIP, German) View the requirements

Free under CC BY-SA 4.0, no registration. User-defined modules under BSI Standard 200-2, no official BSI requirements. Titles on this page are working translations; the documents are available in German only and the German edition is authoritative.

Select a cell to see the requirement, its level, the responsible role and the MHC it implements.

23 requirements in 5 modules

14 basic, 6 standard and 3 requirements for elevated protection. All 13 MHC are covered.

bd.1
bd.2.1
bd.2.2
bd.2.3
bd.2.4

What changes with version 2.0

Module family
One process module and four system modules, each with one modelling rule, instead of a single module.
Policy and technology separated
Phishing-resistant MFA, backup and AI agents: specified in MRIS.bd.1, enforced at the target object.
EU AI Act
Role (provider or deployer) and classification per AI agent in the inventory; 10 informative mappings to provisions of the AI Act.
IT-Grundschutz terms instead of SoA
Security concept, modelling, IT-Grundschutz check and “dispensable”. The SoA remains only as a note for ISO 27001 on the basis of IT-Grundschutz.
21 new requirement sentences
From feedback and the implementation guidance v1.3. MUST only in basic requirements, one modal verb per sentence.
YAML as master
Structure, requirement texts and the origin of every sentence in one file; modules and cross-reference table are generated from it.

All changes in the change log (PDF, German)

One process module, four system modules

The process module regulates what has to be specified once for the entire information domain; the system modules implement it technically at the target objects. Each module has exactly one modelling rule and supplements the modules of the IT-Grundschutz Compendium that apply to these target objects anyway. It does not replace any of them.

MRIS.bd.1, process module

Mythos-Resistant Hardening of the ISMS

Target objects
entire information domain (once)
Requirements
11: 6 basic, 4 standard, 1 elevated protection
Responsible
CISO; further roles: IT operations, developers
Supplements
ISMS.1, ORP.4, ORP.5, CON.1, CON.3, CON.8, OPS.1.1.3, DER.1, DER.2.1, DER.3.1
Modelling rule

Applied once to the entire information domain. The system modules MRIS.bd.2.1 to MRIS.bd.2.4 are additionally applied to their respective target objects.

MRIS.bd.2.1, system module

Identity and Access Systems

Target objects
identity providers, directory services, remote access, PAM systems, applications with their own login
Requirements
2: 1 basic, 1 standard
Responsible
IT operations
Supplements
ORP.4, APP.2.1, APP.2.2, APP.2.3, NET.3.3
Modelling rule

Applied to every identity provider, directory service, remote access (e.g. VPN) and privileged access management (PAM) system, and to every application with its own login for whose accounts MRIS.bd.1.A2 specifies phishing-resistant methods. If an application delegates login to an identity provider, modelling the identity provider is sufficient.

MRIS.bd.2.2, system module

Backup Systems

Target objects
systems that store or manage backups
Requirements
2: 2 basic
Responsible
IT operations
Supplements
CON.3, SYS.1.8
Modelling rule

Applied to every system that stores or manages backups, e.g. backup servers, storage systems for backup copies and cloud backup services.

MRIS.bd.2.3, system module

Execution Platforms

Target objects
container, virtualisation and cloud platforms
Requirements
3: 1 basic, 2 elevated protection
Responsible
IT operations; further roles: developers
Supplements
SYS.1.5, SYS.1.6, APP.4.4, OPS.2.2
Modelling rule

Applied to every platform on which production applications and services run, in particular container orchestration, virtualisation and cloud platforms (IaaS, PaaS). Some requirements apply only under a condition, e.g. when operating containers or multi-tenant services; if the condition does not apply to a platform as a whole, the requirement is marked as dispensable in the IT-Grundschutz check, with justification.

MRIS.bd.2.4, system module

AI Agents

Target objects
AI agents and agentic workflows in production use
Requirements
5: 4 basic, 1 standard
Responsible
IT operations; further roles: developers, business owners
Supplements
no Compendium module
Modelling rule

Applied to every AI agent and agentic workflow in production use. Similar AI agents can be grouped according to the rules of the structure analysis. The IT-Grundschutz Compendium contains no module for AI agents; points of contact exist with ORP.4 and OPS.1.1.5.

15 specific threats

Since mid-2026, agentic frontier AI models of the Mythos class have been broadly available across providers. Many effectiveness assumptions of the deliberately technology-neutral Compendium still rely on the limited patience, speed and capacity of human attackers. The process module names five cross-cutting shifts, the system modules ten threats to their target objects.

bd.1 Mythos-Resistant Hardening of the ISMS

  1. bd.1.G1Collapse of the patch-to-exploit windowUnder AI conditions, hours rather than days or weeks pass between the release of a patch and the availability of a working exploit.
  2. bd.1.G2Compression of the response timelineAI-driven attacks progress faster than human response chains can decide.
  3. bd.1.G3Fragmentation of attacks into inconspicuous micro-stepsAgentic attackers break an overall attack into individual actions that each look like legitimate technical requests.
  4. bd.1.G4Decoupling of attacker capability from actor typeThe capacity barrier between opportunistic attackers and highly professional attacker groups has largely disappeared.
  5. bd.1.G5Unregulated use of privileged AI agentsAI agents in production use with far-reaching rights form a new, often unmanaged attack surface within the organisation.

bd.2.1 Identity and Access Systems

  1. bd.2.1.G1AI-assisted phishing at spear-phishing levelAgentic AI models generate individualised, linguistically flawless phishing campaigns in any number, so users can no longer be relied on to spot them.
  2. bd.2.1.G2Circumvention via fallback and recovery proceduresIf weaker methods remain active as a fallback or the recovery of authenticators is unprotected, attackers deliberately switch to these paths.

bd.2.2 Backup Systems

  1. bd.2.2.G1Manipulation of backups via compromised administrative rightsIf backups are managed with production rights, compromised administrator accounts can delete or encrypt backups or lift their immutability.
  2. bd.2.2.G2Attack completed before detectionAI-driven attacks can be completed before detection and response take effect; recoverability alone then determines the damage.

bd.2.3 Execution Platforms

  1. bd.2.3.G1Lateral movement via shared secrets and network trustLong-lived shared secrets and authorisation based on network location let attackers move between services unnoticed after initial access.
  2. bd.2.3.G2Manipulated images in the supply chainUnsigned or unverified images can bring manipulated components into production unnoticed.
  3. bd.2.3.G3Cross-tenant propagationIf tenant separation is implemented only at application level, a single error is enough for an attacker to reach other tenants.

bd.2.4 AI Agents

  1. bd.2.4.G1Takeover of AI agents through prompt injection and manipulated tool definitionsA hijacked AI agent acts with its own rights inside the legitimate infrastructure, without the attacker needing credentials of their own.
  2. bd.2.4.G2Blanket rights and lack of attributabilityAI agents with blanket rights under personal user accounts and without an audit trail can neither be constrained nor properly attributed.
  3. bd.2.4.G3Uncontrolled agentic componentsMCP servers, IDE extensions and skills from unverified sources extend AI agents with code that lies outside any security consideration.

Cross-reference to the elementary threats

A dot means: the requirement counters the elementary threat of the IT-Grundschutz Compendium. 23 requirements, 19 elementary threats, 61 mappings; identical to the cross-reference table in the package.

Cross-reference: requirements and elementary threats
Requirement0.140.150.180.190.200.210.230.280.290.300.310.320.360.370.390.400.420.450.46Total
bd.1.A11
bd.1.A23
bd.1.A33
bd.1.A43
bd.1.A53
bd.1.A63
bd.1.A73
bd.1.A82
bd.1.A93
bd.1.A103
bd.1.A114
bd.2.1.A13
bd.2.1.A22
bd.2.2.A12
bd.2.2.A23
bd.2.3.A14
bd.2.3.A23
bd.2.3.A33
bd.2.4.A12
bd.2.4.A21
bd.2.4.A32
bd.2.4.A42
bd.2.4.A53
Total313255742425424132261
Names of the elementary threats
  • G 0.14 Interception of information / espionage
  • G 0.15 Eavesdropping
  • G 0.18 Poor planning or lack of adaptation
  • G 0.19 Disclosure of sensitive information
  • G 0.20 Information or products from an unreliable source
  • G 0.21 Manipulation of hardware or software
  • G 0.23 Unauthorised access to IT systems
  • G 0.28 Software vulnerabilities or errors
  • G 0.29 Violation of laws or regulations
  • G 0.30 Unauthorised use or administration of devices and systems
  • G 0.31 Incorrect use or administration of devices and systems
  • G 0.32 Misuse of authorisations
  • G 0.36 Identity theft
  • G 0.37 Repudiation of actions
  • G 0.39 Malware
  • G 0.40 Denial of service
  • G 0.42 Social engineering
  • G 0.45 Data loss
  • G 0.46 Loss of integrity of sensitive information

23 requirements, three levels, five modules

Every requirement with its sentences, the MHC it implements, the responsible role, the reference to ISO/IEC 27002 and a measurement. Titles are working translations; the requirement sentences are shown in the authoritative German original. Sentences with an AI Act reference are marked.

23 of 23 requirements.

MRIS.bd.1 Mythos-Resistant Hardening of the ISMS

bd.1.A1Reassessing the Effectiveness Assumptions of Existing Security MeasuresBasic

Requirement text, German original (authoritative):

  1. Die Institution MUSS die Wirksamkeits- und Wahrscheinlichkeitsannahmen der implementierten Sicherheitsmaßnahmen gegen die KI-beschleunigte Bedrohungslage neu bewerten.
  2. Sicherheitsmaßnahmen, deren Schutzwirkung überwiegend auf Angreiferreibung statt auf einer harten strukturellen Barriere beruht, MÜSSEN dabei identifiziert werden.
  3. Die Ergebnisse der Neubewertung MÜSSEN in die Risikoanalyse einfließen.
  4. Falls die Schutzwirkung einer Maßnahme als degradiert bewertet wird, dann MUSS über Härtung, Kompensation oder begründete Risikoübernahme entschieden werden.
  5. Die Neubewertung MUSS bei wesentlichen Änderungen der Bedrohungslage wiederholt werden.
Implements
cross-cutting, no single MHC
Responsible
CISO
ISO/IEC 27002
corresponds to Annex A (complete)
Threats
bd.1.G1, bd.1.G2, bd.1.G3, bd.1.G4, bd.1.G5 G 0.18
Measurement, German original
Anteil der neu bewerteten Annex-A-Maßnahmen (Zielwert 100 %); dokumentierte Entscheidung je degradierter Maßnahme
bd.1.A2Specifying Phishing-Resistant Multi-Factor AuthenticationBasic

Requirement text, German original (authoritative):

  1. Die Institution MUSS in einer Authentisierungsrichtlinie festlegen, für welche Benutzenden, Anwendungen und Zugänge phishing-resistente Verfahren verpflichtend sind.
  2. In der Authentisierungsrichtlinie MÜSSEN je Zugangsklasse die zugelassenen Verfahren festgelegt werden.
  3. Für alle privilegierten Zugänge MÜSSEN Verfahren nach FIDO2/WebAuthn (Passkeys oder Hardware-Token) festgelegt werden.
  4. Für alle Zugänge zu extern erreichbaren Diensten MÜSSEN phishing-resistente Verfahren festgelegt werden.
  5. Für Zugänge zu Systemen mit erhöhtem Schutzbedarf SOLLTEN phishing-resistente Verfahren festgelegt werden.
  6. SMS-basierte Verfahren und einfache Push-Bestätigungen ohne Number-Matching DÜRFEN für neue Zugänge NICHT eingesetzt werden.
  7. Für bestehende Legacy-MFA-Verfahren MUSS ein Ablösungsplan mit Termin dokumentiert werden.
  8. Ausnahmen von der Authentisierungsrichtlinie MÜSSEN befristet werden.
  9. Ausnahmen MÜSSEN mit Begründung dokumentiert werden.
  10. Die Registrierungs- und Wiederherstellungsprozesse für Authentisierungsmittel MÜSSEN gegen Social Engineering abgesichert werden.
  11. Die Authentisierungsrichtlinie SOLLTE regelmäßig überprüft werden.
Implements
MHC-03 Phishing-Resistant MFA
Responsible
CISO
ISO/IEC 27002
flanks A.5.17, A.8.5
Threats
bd.1.G4 G 0.23, G 0.36, G 0.42
Measurement, German original
Anteil der Anmeldungen über phishing-resistente Verfahren je Zugangsklasse (Zielwert: vollständige Abdeckung der privilegierten und extern erreichbaren Zugänge)
bd.1.A3Maintaining Immutable Backups with Regular Restore TestsBasic

Requirement text, German original (authoritative):

  1. Für alle geschäftskritischen Datenbestände MUSS mindestens eine unveränderliche oder vom Netz getrennte Sicherungskopie vorgehalten werden.
  2. Die Datensicherung SOLLTE nach dem 3-2-1-1-0-Prinzip aufgebaut werden.
  3. Wiederherstellungstests MÜSSEN mindestens vierteljährlich durchgeführt werden.
  4. Die Wiederherstellungstests MÜSSEN dokumentiert werden.
  5. Falls ein Wiederherstellungstest fehlschlägt, dann MUSS die Ursache unverzüglich behoben werden.
Implements
MHC-08 Immutable Backups
Responsible
IT operations
ISO/IEC 27002
deepens A.8.13
Threats
bd.1.G2, bd.1.G4 G 0.39, G 0.45, G 0.46
Measurement, German original
Erfolgsquote der vierteljährlichen Wiederherstellungstests (Zielwert 100 %)
bd.1.A4Establishing Behaviour-Based Attack Detection with Event CorrelationBasic

Requirement text, German original (authoritative):

  1. Die Institution MUSS über Verfahren zur Erkennung von Angriffen anhand von Verhaltensauffälligkeiten und der Korrelation zusammenhängender Ereignisse verfügen.
  2. Die Erkennungsregeln MÜSSEN sich an einem anerkannten Katalog von Angriffstechniken (MITRE ATT&CK) orientieren.
  3. Die Abdeckung der wichtigsten Angriffstechniken MUSS gemessen werden.
  4. Die gemessene Abdeckung MUSS regelmäßig überprüft werden.
  5. Threat-Hunting SOLLTE als feste Funktion mit dokumentierter Methodik etabliert werden.
  6. Falls kein eigenes Security Operations Center betrieben wird, dann SOLLTE ein Managed-Detection-and-Response-Dienst mit vergleichbarem Leistungsumfang beauftragt werden.
Implements
MHC-05 Behavior-Based Detection
Responsible
CISO
ISO/IEC 27002
flanks A.8.16, A.8.12
Threats
bd.1.G2, bd.1.G3 G 0.23, G 0.32, G 0.39
Measurement, German original
Gemessene und durch Tests bestätigte ATT&CK-Abdeckung (Richtwert ≥ 60 % der zehn wichtigsten Techniken der eigenen Branche); Zahl und Ergebnis der Hunts
bd.1.A5Creating a Cryptographic Inventory and a Post-Quantum Migration StrategyBasic

Requirement text, German original (authoritative):

  1. Die Institution MUSS ein Inventar aller eingesetzten kryptografischen Verfahren, Schlüssellängen und Implementierungen führen.
  2. Falls Daten mit langer Vertraulichkeitsdauer verarbeitet werden, dann MUSS eine dokumentierte Migrationsstrategie zu quantensicheren Verfahren vorliegen.
  3. Falls Daten mit langer Vertraulichkeitsdauer übertragen werden, dann SOLLTEN im Übergang hybride Verfahren eingesetzt werden.
  4. Inventar und Strategie MÜSSEN mindestens jährlich oder anlassbezogen überprüft werden.
  5. Bei Neubeschaffungen SOLLTE die Unterstützung quantensicherer oder austauschbarer Verfahren als Anforderung aufgenommen werden.
Implements
MHC-01 Post-Quantum Strategy and Cryptographic Inventory
Responsible
CISO
ISO/IEC 27002
flanks A.8.24
Threats
bd.1.G4 G 0.14, G 0.15, G 0.19
Measurement, German original
Anteil der erfassten und nach Migrationspriorität eingestuften Verfahren; Toleranzgrenze: keine langlebig vertraulichen Daten ohne Migrationsplan
bd.1.A6Regulated Use of AI AgentsBasic

Requirement text, German original (authoritative):

  1. Die Institution MUSS ein Inventar aller produktiv eingesetzten KI-Agenten und agentischen Abläufe führen.
  2. Das Inventar MUSS selbst entwickelte Agenten ebenso umfassen wie Agenten, die als Software-as-a-Service oder über Low-Code- und No-Code-Plattformen betrieben werden.
  3. Das Inventar MUSS je KI-Agent ausweisen, welche Rolle die Institution nach der KI-Verordnung einnimmt (Anbieter, Betreiber oder beides) und wie das zugrunde liegende KI-System eingestuft ist.AI Act
  4. Bei wesentlichen Änderungen an einem KI-Agenten SOLLTE geprüft werden, ob sich die Rolle der Institution dadurch ändert.AI Act
  5. Falls KI-Agenten produktiv eingesetzt werden, dann MÜSSEN diese wie privilegierte Systeme behandelt werden.
  6. Für jeden produktiven KI-Agenten MUSS eine verantwortliche Person benannt werden.AI Act
  7. Für agentische Komponenten wie MCP-Server, IDE-Erweiterungen und Skills MUSS eine Freigabeliste gepflegt werden.
Implements
MHC-13 AI Agent Governance
Responsible
CISO
ISO/IEC 27002
extends A.5.9, A.5.16, A.8.27
Threats
bd.1.G5 G 0.20, G 0.29, G 0.30
Measurement, German original
Inventar-Abdeckung (Zielwert 100 %); Governance-Abdeckung: Anteil mit dokumentiertem Bedrohungsmodell, benannter verantwortlicher Person, begrenzter Identität und Berechtigungsgrenzen (Zielwert 100 %)
bd.1.A7Generating SBOMs and Build Provenance EvidenceStandard

Requirement text, German original (authoritative):

  1. Für jede selbst erstellte und weitergegebene Software SOLLTE automatisch in der Build-Pipeline eine Software-Stückliste (SBOM) in einem standardisierten Format erzeugt werden.
  2. Die Stückliste SOLLTE auch die transitiven Abhängigkeiten erfassen.
  3. Die erfassten Komponenten SOLLTEN automatisiert gegen Schwachstellendatenbanken abgeglichen werden.
  4. Falls eine neue Schwachstelle bekannt wird, dann SOLLTE die eigene Betroffenheit anhand der Stücklisten innerhalb von 24 Stunden ermittelbar sein.
  5. Für kritische Artefakte SOLLTE eine manipulationssichere Build-Provenance vorgehalten werden.
  6. Von kritischen Softwarelieferanten SOLLTE die Bereitstellung einer Stückliste vertraglich eingefordert werden.
Implements
MHC-02 SBOM and Build Provenance
Responsible
developers
ISO/IEC 27002
flanks A.5.21, A.8.30
Threats
bd.1.G1 G 0.20, G 0.21, G 0.28
Measurement, German original
SBOM-Coverage: Anteil der ausgelieferten Artefakte mit aktueller, automatisch erzeugter Stückliste (Zielwert: vollständige Abdeckung)
bd.1.A8Integrating Automated Security Testing into the Development PipelineStandard

Requirement text, German original (authoritative):

  1. Sicherheitsprüfungen des Quellcodes, der Abhängigkeiten und der laufenden Anwendung SOLLTEN automatisiert in der Entwicklungs-Pipeline bei jeder Änderung ausgeführt werden.
  2. Schwerwiegende Funde SOLLTEN die Übernahme in den Hauptzweig blockieren.
  3. KI-generierter Code SOLLTE als eigener Risikofaktor im Standard für sichere Entwicklung und in der Risikobewertung berücksichtigt werden.
  4. KI-generierter Code SOLLTE zusätzlich geprüft werden.
  5. Für geeignete Anwendungen SOLLTEN ergänzend KI-gestützte Testverfahren eingesetzt werden.
  6. Falls eine aktiv ausgenutzte Schwachstelle in einer eingesetzten Komponente bekannt wird, dann SOLLTE für internet-exponierte Systeme innerhalb von 24 Stunden eine wirksame Behebung umgesetzt werden.
  7. Als wirksame Behebung gelten Patch, Umgehungslösung, kompensierende Maßnahme, Trennung vom Netz oder Ablösung der Komponente.
Implements
MHC-09 AI-Assisted Security Testing
Responsible
developers
ISO/IEC 27002
flanks A.8.29, A.8.25
Threats
bd.1.G1 G 0.21, G 0.28
Measurement, German original
Behebungslatenz für aktiv ausgenutzte Schwachstellen (KEV) ab Verfügbarkeit einer belastbaren Behebung (Richtwert für internet-exponierte Systeme < 24 h); Anteil der Pipelines mit Sicherheitsprüfung und Pre-Merge-Block
bd.1.A9Automating Incident Response with Hardened PlaybooksStandard

Requirement text, German original (authoritative):

  1. Für eindeutige Vorfallstypen SOLLTEN vordefinierte, automatisierte Reaktions-Playbooks vorliegen.
  2. Die Eindämmung eindeutiger Vorfälle SOLLTE automatisiert innerhalb von Minuten eingeleitet werden.
  3. Mehrdeutige oder schwerwiegende Fälle SOLLTEN gezielt an dafür zuständige Personen eskaliert werden.
  4. Falls eine automatische Aktion eine große Schadwirkung entfalten kann, dann SOLLTE vor der Ausführung eine menschliche Freigabe erfolgen.
  5. Die Automatisierungsschicht selbst SOLLTE gehärtet werden, insbesondere durch authentisierte Auslöser, vollständigen Audit-Trail und Rate-Limits.
  6. Übungen für mehrere parallele Vorfälle SOLLTEN mindestens halbjährlich durchgeführt werden.
  7. Falls kein eigenes Security-Team vorhanden ist, dann KANN ein Managed-Detection-and-Response-Dienst mit vertraglich vereinbarter Eindämmungszeit genutzt werden.
Implements
MHC-11 SOAR and Tier-1 Automation
Responsible
CISO
ISO/IEC 27002
supplements A.5.24, A.5.25, A.5.26
Threats
bd.1.G2 G 0.23, G 0.39, G 0.40
Measurement, German original
Zeit bis zur Eindämmung eindeutiger Vorfälle (Richtwert < 10 min bei hoher Eindeutigkeit)
bd.1.A10Establishing Continuous Automated Effectiveness VerificationStandard

Requirement text, German original (authoritative):

  1. Die Einhaltung der im Sicherheitskonzept vorgesehenen Sicherheitsmaßnahmen SOLLTE laufend und automatisiert gegen festgelegte Soll-Zustände geprüft werden.
  2. Sicherheitsvorgaben SOLLTEN, wo möglich, als ausführbare Regeln (Policy-as-Code) formuliert werden.
  3. Diese Regeln SOLLTEN in die Bereitstellungs- und Betriebsprozesse eingebunden werden.
  4. Abweichungen SOLLTEN alarmiert werden.
  5. Abweichungen SOLLTEN nachverfolgt werden.
  6. Eine automatisierte Reaktion auf Abweichungen SOLLTE angestrebt werden.
  7. Die Institution SOLLTE dokumentieren, welche Sicherheitsmaßnahmen technisch automatisiert prüfbar sind.
  8. Der Anteil der automatisiert geprüften Maßnahmen SOLLTE bezogen auf diese als automatisierbar eingestuften Maßnahmen gemessen werden.
  9. Dieser Anteil SOLLTE schrittweise erhöht werden.
Implements
MHC-10 Continuous Control Monitoring
Responsible
CISO
ISO/IEC 27002
supports A.5.35, A.5.36
Threats
bd.1.G2 G 0.18, G 0.29, G 0.31
Measurement, German original
Automatisierungs-Eignung: Anteil der im Sicherheitskonzept vorgesehenen Maßnahmen, die technisch automatisiert prüfbar sind; Continuous-Monitoring-Coverage (Richtwerte ≥ 60 % nach 12, ≥ 80 % nach 24 Monaten)
bd.1.A11Conducting Threat-Led Penetration Tests with AI ScenariosElevated protection

Requirement text, German original (authoritative):

  1. Die Wirksamkeit der Schutzmaßnahmen SOLLTE regelmäßig durch bedrohungsgeleitete Penetrationstests (Threat-Led Penetration Testing) geprüft werden.
  2. Die Testszenarien SOLLTEN KI-typische Vorgehensweisen einschließen, insbesondere fragmentierte Angriffsketten, parallele Multi-Vector-Angriffe und KI-gestütztes Spear-Phishing.
  3. Zwischen den Testzyklen SOLLTEN gemeinsame Übungen von Angriffs- und Verteidigungsseite (Purple Team) stattfinden.
  4. Festgestellte kritische Funde SOLLTEN innerhalb eines vereinbarten Zeitfensters behoben werden.
Implements
MHC-12 Threat-Led Penetration Testing
Responsible
CISO
ISO/IEC 27002
supplements A.5.35, A.8.29
Threats
bd.1.G1, bd.1.G2, bd.1.G3, bd.1.G4 G 0.18, G 0.23, G 0.28, G 0.42
Measurement, German original
Closure-Rate: Anteil der Funde, die im vereinbarten Zeitfenster behoben werden (Richtwert ≥ 90 %)

MRIS.bd.2.1 Identity and Access Systems

bd.2.1.A1Enforcing Phishing-Resistant AuthenticationBasic

Requirement text, German original (authoritative):

  1. Auf dem System MÜSSEN die Verfahren aktiviert werden, die in der Authentisierungsrichtlinie für seine Zugänge festgelegt sind.
  2. Die Anmeldung über diese Zugänge MUSS technisch auf die festgelegten Verfahren beschränkt werden.
  3. Nicht zugelassene Verfahren DÜRFEN auch als Rückfalloption NICHT angeboten werden.
Implements
MHC-03 Phishing-Resistant MFA
Responsible
IT operations
ISO/IEC 27002
flanks A.5.17, A.8.5
Threats
bd.2.1.G1, bd.2.1.G2 G 0.23, G 0.36, G 0.42
Measurement, German original
Anteil der Zugänge des Systems, die technisch auf die festgelegten Verfahren beschränkt sind (Zielwert 100 %); keine aktive Rückfalloption mit nicht zugelassenen Verfahren
bd.2.1.A2Logging Authentication EventsStandard

Requirement text, German original (authoritative):

  1. Das bei einer Anmeldung verwendete Authentisierungsverfahren SOLLTE protokolliert werden.
  2. Die Registrierung und die Änderung von Authentisierungsmitteln SOLLTEN protokolliert werden.
Implements
MHC-03 Phishing-Resistant MFA
Responsible
IT operations
ISO/IEC 27002
flanks A.5.17, A.8.5
Threats
bd.2.1.G2 G 0.36, G 0.37
Measurement, German original
Anteil der Anmeldungen mit protokolliertem Verfahren (Zielwert 100 %); Datengrundlage der Kennzahl zu MRIS.bd.1.A2

MRIS.bd.2.2 Backup Systems

bd.2.2.A1Separating the Administration of the Backup SystemBasic

Requirement text, German original (authoritative):

  1. Das Datensicherungssystem MUSS über eigene, von der Produktionsumgebung getrennte Zugriffswege und Berechtigungen verwaltet werden.
  2. Zugangsdaten für die Administration des Datensicherungssystems SOLLTEN NICHT in der Produktionsumgebung hinterlegt werden.
Implements
MHC-08 Immutable Backups
Responsible
IT operations
ISO/IEC 27002
deepens A.8.13
Threats
bd.2.2.G1 G 0.30, G 0.32
Measurement, German original
Nachweis der getrennten Rechtevergabe; kein Administrationskonto der Produktionsumgebung mit Zugriff auf das Datensicherungssystem
bd.2.2.A2Technically Enforcing ImmutabilityBasic

Requirement text, German original (authoritative):

  1. Falls Sicherungskopien unveränderlich vorgehalten werden, dann MUSS die Unveränderlichkeit technisch erzwungen werden.
  2. Die Aufbewahrungssperre MUSS so konfiguriert werden, dass sie während der Aufbewahrungsfrist auch mit administrativen Rechten nicht aufgehoben werden kann.
  3. Die Aufbewahrungs- und Sperreinstellungen SOLLTEN dokumentiert werden.
Implements
MHC-08 Immutable Backups
Responsible
IT operations
ISO/IEC 27002
deepens A.8.13
Threats
bd.2.2.G1, bd.2.2.G2 G 0.39, G 0.45, G 0.46
Measurement, German original
Nachweis der Aufbewahrungs- und Sperreinstellungen; Test, dass die Sperre nicht mit administrativen Rechten aufhebbar ist

MRIS.bd.2.3 Execution Platforms

bd.2.3.A1Introducing Workload Identities and Identity-Based Access ControlBasic

Requirement text, German original (authoritative):

  1. Privilegierte Service-Konten und Workloads MÜSSEN mit kryptografisch verifizierbaren, kurzlebigen Identitäten ausgestattet werden.
  2. Die Kommunikation zwischen kritischen Diensten MUSS anhand dieser Workload-Identität autorisiert werden.
  3. Die Netzwerklage allein DARF NICHT als Autorisierungsgrundlage dienen.
  4. Langlebige, im Klartext gespeicherte gemeinsame Geheimnisse DÜRFEN auf kritischen Kommunikationspfaden NICHT eingesetzt werden.
  5. Die Kommunikation zwischen produktiven Diensten SOLLTE durchgängig mit mTLS abgesichert werden.
  6. Die Umstellung SOLLTE stufenweise erfolgen, beginnend mit den privilegierten Workloads.
Implements
MHC-04 Workload Identity and Zero Trust
Responsible
IT operations
ISO/IEC 27002
flanks A.5.16, A.8.20, A.8.21
Threats
bd.2.3.G1 G 0.23, G 0.30, G 0.32, G 0.36
Measurement, German original
Anteil der produktiven Dienst-zu-Dienst-Verbindungen mit Workload-Identität und mTLS (Richtwerte: Stufe 1 ≥ 80 % der privilegierten Service-Workloads, Stufe 2 mTLS für ≥ 95 % des Ost-West-Verkehrs); Zeit bis zum Entzug einer Identität
bd.2.3.A2Using Signed Container Images and Protected Execution EnvironmentsElevated protection

Requirement text, German original (authoritative):

  1. Falls auf der Plattform produktive Container betrieben werden, dann SOLLTEN diese ausschließlich aus signierten, vor dem Start geprüften Images aus kontrollierten Registries gestartet werden.
  2. Die Prüfung SOLLTE technisch über die Plattform durchgesetzt werden, etwa mit Admission-Controller-Policies.
  3. Falls Workloads einen besonders hohen Schutzbedarf haben, dann SOLLTEN geschützte Ausführungsumgebungen (Confidential Computing) mit Remote-Attestation eingesetzt werden.
Implements
MHC-06 Containers and Confidential Computing
Responsible
IT operations
ISO/IEC 27002
flanks A.5.23, A.8.31
Threats
bd.2.3.G2 G 0.14, G 0.20, G 0.21
Measurement, German original
Anteil der produktiven Container aus signierten, geprüften Images (Zielwert: vollständig); Abdeckung von Confidential Computing bei hochsensiblen Workloads; Toleranzgrenze: kein produktiver Container ohne gültige Signatur und Prüfung
bd.2.3.A3Implementing Verifiable Tenant SeparationElevated protection

Requirement text, German original (authoritative):

  1. Falls mandantenfähige Dienste betrieben werden, dann SOLLTEN Daten, Netzwerke und Rechenressourcen je Mandant getrennt werden.
  2. Die Datentrennung SOLLTE mit mandantenspezifischen Schlüsseln umgesetzt werden.
  3. Die Wirksamkeit der Trennung SOLLTE durch regelmäßige, möglichst automatisierte Tests nachgewiesen werden.
  4. Falls ein mandantenübergreifender Zugriff festgestellt wird, dann SOLLTE dieser unverzüglich unterbunden werden.
Implements
MHC-07 Multi-Tenancy Isolation
Responsible
IT operations
ISO/IEC 27002
flanks A.5.23, A.8.22
Threats
bd.2.3.G3 G 0.14, G 0.19, G 0.23
Measurement, German original
Ergebnis der Trennungstests (kein mandantenübergreifender Zugriff nachweisbar); Häufigkeit und Abdeckung der Tests

MRIS.bd.2.4 AI Agents

bd.2.4.A1Setting Up a Limited Identity for the AI AgentBasic

Requirement text, German original (authoritative):

  1. Der KI-Agent MUSS eine technische, auf die erforderlichen Rechte begrenzte Identität erhalten.
  2. Falls die eingesetzte Plattform keine agentenspezifische Identität unterstützt, dann MUSS eine kontrollierte Delegation mit minimalen Rechten über ein eigenes Dienstkonto erfolgen.
  3. Die Berechtigungsgrenzen dieser Delegation MÜSSEN dokumentiert werden.
Implements
MHC-13 AI Agent Governance
Responsible
IT operations
ISO/IEC 27002
extends A.5.9, A.5.16, A.8.27
Threats
bd.2.4.G2 G 0.30, G 0.32
Measurement, German original
Zeit bis zum Entzug kompromittierter Agent-Identitäten (Zielwert < 5 min)
bd.2.4.A2Logging the Actions of the AI AgentBasic

Requirement text, German original (authoritative):

  1. Aktionen des KI-Agenten mit Schreib- oder Netzwerkrechten MÜSSEN lückenlos und der auslösenden menschlichen Identität zuordenbar protokolliert werden.AI Act
  2. Die Aufbewahrungsdauer der Protokolle SOLLTE unter Berücksichtigung gesetzlicher, vertraglicher und forensischer Anforderungen festgelegt werden.AI Act
Implements
MHC-13 AI Agent Governance
Responsible
IT operations
ISO/IEC 27002
extends A.5.9, A.5.16, A.8.27
Threats
bd.2.4.G2 G 0.37
Measurement, German original
Protokollierungs-Abdeckung für Aktionen mit Schreib- oder Netzwerkrechten (Zielwert 100 %)
bd.2.4.A3Ensuring Human Oversight of the AI AgentBasic

Requirement text, German original (authoritative):

  1. Der KI-Agent MUSS durch die verantwortliche Person abgeschaltet werden können.AI Act
  2. Irreversible Aktionen des KI-Agenten MÜSSEN eine menschliche Freigabe erfordern.AI Act
Implements
MHC-13 AI Agent Governance
Responsible
IT operations
ISO/IEC 27002
extends A.5.9, A.5.16, A.8.27
Threats
bd.2.4.G1 G 0.31, G 0.32
Measurement, German original
Nachweis der Abschaltmöglichkeit und der Freigabeschwellen für irreversible Aktionen
bd.2.4.A4Restricting the Agent to Approved Agentic ComponentsBasic

Requirement text, German original (authoritative):

  1. Für den KI-Agenten DÜRFEN NUR agentische Komponenten eingesetzt werden, die in der Freigabeliste geführt sind.
  2. Diese Beschränkung SOLLTE technisch durchgesetzt werden.
Implements
MHC-13 AI Agent Governance
Responsible
IT operations
ISO/IEC 27002
extends A.5.9, A.5.16, A.8.27
Threats
bd.2.4.G3 G 0.20, G 0.21
Measurement, German original
Anteil der eingesetzten agentischen Komponenten, die in der Freigabeliste geführt sind (Zielwert 100 %)
bd.2.4.A5Reviewing the Agent Controls Before Production ReleaseStandard

Requirement text, German original (authoritative):

  1. Falls Prompts, Werkzeugdefinitionen, Retrieval-Pipelines oder Eskalationslogik des KI-Agenten unter der Kontrolle der Institution stehen, dann SOLLTEN diese Komponenten wie Produktivcode einem Code-Review unterzogen werden.AI Act
  2. Falls diese Komponenten vom Hersteller kontrolliert werden, dann SOLLTEN stattdessen Nachweise des Herstellers zu ihrer Absicherung eingefordert werden.AI Act
  3. Vor der Produktivsetzung SOLLTE der KI-Agent auf Anfälligkeit für Prompt-Injection und Confused-Deputy-Angriffe getestet werden.AI Act
Implements
MHC-13 AI Agent Governance
Responsible
IT operations
ISO/IEC 27002
extends A.5.9, A.5.16, A.8.27
Threats
bd.2.4.G1, bd.2.4.G3 G 0.20, G 0.21, G 0.28
Measurement, German original
Anteil der produktiven KI-Agenten mit dokumentierter Prüfung vor der Produktivsetzung (Zielwert 100 %)

Adopting it into the security concept

Modelling
Model MRIS.bd.1 once for the entire information domain and MRIS.bd.2.1 to MRIS.bd.2.4 for the respective target objects. If there are no target objects of a type, the corresponding system module is omitted.
IT-Grundschutz check
Requirements that do not apply are marked as dispensable and justified, typically MRIS.bd.1.A7 and A8 without in-house software development (the principle then works through procurement) and MRIS.bd.2.3.A3 without multi-tenant operation.
Sequence
Reassessment (MRIS.bd.1.A1) before investment. Detection (A4) before response automation (A9). SBOMs (A7) before pipeline testing (A8). Policy in MRIS.bd.1 before enforcement in the system modules. Threat-led testing (A11) after the basic implementation.
Responsibilities
Primarily responsible are the CISO for MRIS.bd.1 and IT operations for the system modules. Further roles: developers (MRIS.bd.1, MRIS.bd.2.3, MRIS.bd.2.4) and business owners (MRIS.bd.2.4).
ISO 27001 on the basis of IT-Grundschutz
The IT-Grundschutz methodology has no SoA. For an ISO 27001 certification on the basis of IT-Grundschutz, the requirements can additionally be adopted into the Statement of Applicability.
Maturity levels
The implementation guidance describes Initial, Defined and Managed per measure. Only from Defined is a requirement generally considered implemented; Initial documents a started implementation path.

AI agents and the EU AI Act

MRIS.bd.1.A6 requires the inventory to state, for each AI agent, the organization’s role under the AI Act and the classification of the AI system. The resulting legal obligations are implemented via compliance management (ORP.5); they are not requirements of the module family. The security measures apply to all AI agents in production, regardless of their classification.

Provider
Develops an AI system and places it on the market or puts it into service under their own name, including for their own use (Art. 3(3) in conjunction with Art. 3(11)).
Deployer
Uses an AI system under their own authority (Art. 3(4)).
Change of role
After substantial changes to an AI agent, it is checked whether the organization’s role changes (Art. 25(1)).
Application dates
As of September 2026, the obligations for high-risk AI systems under Annex III apply from 2 December 2027 and under Annex I from 2 August 2028.
Informative mapping of requirement sentences to the AI Act
RequirementTitleApplies toRole and provision
bd.1.A6Sentence 3Regulated Use of AI Agentsall AI systemsprovider: Art. 3(3) in conjunction with Art. 3(11)
deployer: Art. 3(4)
both: Art. 6, Art. 50
bd.1.A6Sentence 4Regulated Use of AI Agentshigh-risk AI systemdeployer: Art. 25(1)
bd.1.A6Sentence 6Regulated Use of AI Agentshigh-risk AI systemdeployer: Art. 26(2)
bd.2.4.A2Sentence 1Logging the Actions of the AI Agenthigh-risk AI systemprovider: Art. 12(1)
bd.2.4.A2Sentence 2Logging the Actions of the AI Agenthigh-risk AI systemprovider: Art. 19(1)
deployer: Art. 26(6)
bd.2.4.A3Sentence 1Ensuring Human Oversight of the AI Agenthigh-risk AI systemprovider: Art. 14(4)(e)
deployer: Art. 26(2)
bd.2.4.A3Sentence 2Ensuring Human Oversight of the AI Agenthigh-risk AI systemprovider: Art. 14(4)(d)
deployer: Art. 26(2)
bd.2.4.A5Sentence 1Reviewing the Agent Controls Before Production Releasehigh-risk AI systemprovider: Art. 15(5)
bd.2.4.A5Sentence 2Reviewing the Agent Controls Before Production Releasehigh-risk AI systemdeployer: Art. 26(1) in conjunction with Art. 13
bd.2.4.A5Sentence 3Reviewing the Agent Controls Before Production Releasehigh-risk AI systemprovider: Art. 15(5)

Informative mapping, not a requirement and not legal advice. The governing text is Regulation (EU) 2024/1689 (AI Act) as amended by Regulation (EU) 2026/1744: 2024/1689 on EUR-Lex.

MRIS.bd and the BSI test criteria catalogue A5

Both works deal with AI, from opposite directions. They do not exclude each other; they complement each other.

BSI test criteria catalogue A5

  • AI Audit and Assurance Assessment Architecture, community draft of 6 July 2026
  • Its subject is the AI system itself
  • Assesses the trustworthiness of AI systems along their life cycle
  • Links to the C5 catalogue via an operations module

MRIS.bd module family

  • User-defined modules for IT-Grundschutz
  • Its subject is the ISMS and its target objects
  • Hardens the effectiveness of existing measures against attackers who use AI themselves
  • Treats AI agents as privileged systems with identity, logging and human oversight

Where IT-Grundschutz stands and what MRIS.bd changes

In the MRIS market comparison, BSI IT-Grundschutz sits at high implementation readiness (8.4) but limited Gen-AI coverage (3.0). MRIS.bd addresses this gap where IT-Grundschutz practitioners work: in the modules. The combination keeps the implementation readiness of IT-Grundschutz and adds the Gen-AI coverage of the MRIS layer.

Market comparison from the IT-Grundschutz perspectiveBSI IT-Grundschutz sits at 3.0 Gen-AI coverage and 8.4 implementation readiness; the combination with MRIS.bd at 9.4 and 8.4. All values are in the table below the chart.00224466881010implementation-strong, Gen-AI gapcomprehensively stronglimited positiontopic-strong, implementation openMythos and Gen-AI coverageImplementation readiness and auditabilityMythos-Ready (CSA/SANS/[un]prompted/OWASP): coverage 8.8, readiness 4.6 (programme agenda)Mythos-ReadyOWASP Top 10 for Agentic Applications: coverage 7.8, readiness 3.8 (risk top 10 (community))OWASP Agentic Top 10MITRE ATT&CK v19.2 / ATLAS: coverage 6.8, readiness 6.4 (taxonomy / knowledge base)MITRE ATT&CK / ATLASBSI C5:2026: coverage 5.4, readiness 9.0 (audit catalog)BSI C5:2026NIST AI RMF 1.0 + GenAI-Profil (AI 600-1): coverage 5.0, readiness 5.8 (governance framework)NIST AI RMFISO/IEC 42001:2023: coverage 4.6, readiness 6.2 (management system standard)ISO/IEC 42001BSI A5 (AI Audit and Assurance Assessment Architecture): coverage 3.9, readiness 5.7 (audit catalog, community draft)BSI A5 (draft)CISA Zero Trust Maturity Model v2.0: coverage 4.0, readiness 6.8 (maturity model)CISA Zero TrustNIST CSF 2.0: coverage 3.6, readiness 7.0 (framework)NIST CSF 2.0CSA Cloud Controls Matrix v4: coverage 3.5, readiness 8.6 (control catalog)CSA CCMCIS Controls v8.1: coverage 3.2, readiness 7.6 (practice framework)CIS ControlsISO/IEC 27002:2022: coverage 2.2, readiness 9.0 (standard)ISO/IEC 27002IT-Grundschutz + MRIS.bd: coverage 9.4, readiness 8.4 (combination)IT-Grundschutz + MRIS.bdBSI IT-Grundschutz: coverage 3.0, readiness 8.4 (standard / methodology)BSI IT-Grundschutz
Qualitative expert scoring on a scale from 0 to 10, assessment status August 2026. The combination point follows the combination rule of the market comparison: X equals the Gen-AI coverage of the MRIS layer (9.4), Y the value of IT-Grundschutz (8.4); a premium would only be justified by an externally validated audit scheme for the MHC. BSI A5 is a community draft of 6 July 2026 and not yet a final standard. Full data and reading on the ISO page
All positions as a table
WorkTypeGen-AI coverageReadiness
IT-Grundschutz + MRIS.bdcombination9.48.4
BSI IT-Grundschutzstandard / methodology3.08.4
Mythos-Ready (CSA/SANS/[un]prompted/OWASP)programme agenda8.84.6
OWASP Top 10 for Agentic Applicationsrisk top 10 (community)7.83.8
MITRE ATT&CK v19.2 / ATLAStaxonomy / knowledge base6.86.4
BSI C5:2026audit catalog5.49.0
NIST AI RMF 1.0 + GenAI-Profil (AI 600-1)governance framework5.05.8
ISO/IEC 42001:2023management system standard4.66.2
BSI A5 (AI Audit and Assurance Assessment Architecture)audit catalog, community draft3.95.7
CISA Zero Trust Maturity Model v2.0maturity model4.06.8
NIST CSF 2.0framework3.67.0
CSA Cloud Controls Matrix v4control catalog3.58.6
CIS Controls v8.1practice framework3.27.6
ISO/IEC 27002:2022standard2.29.0

From version 1.3 to 2.0

For anyone who has already modelled MRIS.bd.1 v1.3: where each requirement is now. Version 1.3 has been withdrawn; only version 2.0 applies.

Of 107 requirement sentences, 60 are unchanged, 21 new, 19 adapted and 7 edited. The machine-readable edition records the origin of every sentence.

Mapping of requirements from version 1.3 to version 2.0
Version 1.3Version 2.0Change
bd.1.A1bd.1.A1unchanged
bd.1.A2bd.1.A2, bd.2.1.A1, bd.2.1.A2split: policy / technical
bd.1.A3bd.1.A3, bd.2.2.A1, bd.2.2.A2split: policy / technical
bd.1.A4bd.1.A4unchanged
bd.1.A5bd.2.3.A1moved
bd.1.A6bd.1.A5renumbered
bd.1.A7bd.1.A6, bd.2.4.A1, bd.2.4.A2, bd.2.4.A3, bd.2.4.A4split: policy / technical
bd.1.M7bd.2.4.A5new, from implementation guidance
bd.1.A8bd.1.A7renumbered
bd.1.A9bd.1.A8renumbered, editorial
bd.1.A10bd.1.A9renumbered
bd.1.A11bd.1.A10renumbered, SoA reference replaced, editorial
bd.1.A12bd.2.3.A2moved, applicability condition
bd.1.A13bd.2.3.A3moved
bd.1.A14bd.1.A11renumbered

One package, all documents

The complete package contains all documents of the module family (ZIP, 620 KB, German, edition 2.0, September 2026, CC BY-SA 4.0).

  • MRIS.bd.1 Mythos-Resistant Hardening of the ISMSPDF, 9 pages, 126 KB
  • MRIS.bd.2.1 Identity and Access SystemsPDF, 5 pages, 79 KB
  • MRIS.bd.2.2 Backup SystemsPDF, 5 pages, 76 KB
  • MRIS.bd.2.3 Execution PlatformsPDF, 6 pages, 84 KB
  • MRIS.bd.2.4 AI AgentsPDF, 6 pages, 89 KB
  • Implementation guidance, one measure per requirementPDF, 15 pages, 173 KB
  • Cross-reference table for the elementary threatsXLSX, 22 KB
  • Machine-readable edition, master with origin per sentenceYAML, 51 KB
  • Change log 1.3 to 2.0PDF, 2 pages, 44 KB

SHA-256 of the package: d2f354a5d10ab928a546ad7f3d1708bf8b110474f5fa7f0e32bcc352c3e792c1

MRIS.bd downloads
PublicationEditionDateLicenseFiles
Complete package: 5 modules, implementation guidance, cross-reference table, YAML, change log2.0September 2026CC BY-SA 4.0ZIP
Machine-readable edition2.0September 2026CC BY-SA 4.0YAML
Change log 1.3 to 2.02.020 September 2026–PDF

MRIS.bd is a family of user-defined modules within the meaning of the IT-Grundschutz methodology (BSI Standard 200-2), which explicitly provides for custom modules covering topics not yet addressed. The modules contain no official BSI requirements, have been neither reviewed nor approved by the BSI, are not part of the IT-Grundschutz Compendium and do not replace any certification. MRIS is an independent project and not an offering of the BSI. Use within IT security concepts under IT-Grundschutz is expressly welcome. No legal or certification advice; use at your own responsibility.