Kerberos Compliance: Check authentication, prove risks, pass audit

Kerberos has been the standard protocol for authentication in Microsoft Active Directory since MIT 1988 and is used productively in almost every German company. With ISO/IEC 27001:2022 Annex A.8.5 (Secure Authentication) and the NIS 2 guideline from October 18, 2024, the protocol is moving into the focus of auditors. Anyone who does not document ticket granting tickets, service principals and key derivations cannot provide proof of control in the audit and risks finding at the major level. The Federal Office for Information Security also explicitly refers to minimum requirements for encryption, account separation and incident response in the Active Directory in the IT-Grundschutz component APP.2.2.

This article classifies Kerberos compliance along the three levels that auditors actually query: configuration, operation and reaction. You will learn which cryptographic parameters are permitted today, which Kerberoasting and golden ticket risks you need to demonstrably address, and how findings from Active Directory assessments can be fed back into the information security management system. The article also shows which responsibilities must be clarified between the information security officer, compliance officer and IT operations so that evidence is available immediately in the event of an audit. CIVAC accompanies this process as a compliance platform and officer-as-a-service with audit templates, appointment certificates and reporting lines. Licence the workspace for your internal representatives or have our representatives order it. Both paths lead to the same result: a documented, verifiable Kerberos hardening level.

Kerberos distributes tickets from a key distribution centre and reduces repeated password transmissions. This architecture is advantageous in terms of security, but creates its own test objects: Tickets must be encrypted, keys must be rotated and service accounts must be inventoried. In terms of ISO/IEC 27001:2022 Annex A.5.16 (Identity Management) and A.8.5 (Secure Authentication), the protocol is a central control point, not a technical detail. Kerberos is also named in the BSI basic protection module ORP.4 as a process whose hardening status must be checked periodically.

There are three obligations for compliance. First, you must prove that krb5 configurations use current encryption methods such as AES-256 and legacy suites such as DES or RC4 are disabled. Second, you must demonstrate that tickets expire within reasonable timeframes, typically ten hours of initial ticket validity and seven days of renewable lifetime. Third, you must demonstrate that service principal names are regularly verified and privileged accounts are segregated. The NIS 2 policy heightens this expectation because Active Directory is considered a critical system in essential and important facilities and failures or compromises trigger immediate reporting requirements.

Others run compliance like a filing cabinet. We run it like software. In the CIVAC workspace for the information security officer, Kerberos controls are located as auditable objects with responsible parties, frequencies and receipts. This makes the protocol testable instead of just operationally configured. The management receives a status report in the same system, in which the degree of hardening, review status and open findings are brought together. This creates a continuous thread from technology to organisation to the reporting line to management, which can be presented in the audit without further preparation and shortens discussions about responsibilities. Treating Kerberos as an operational detail overlooks the leverage it has on the overall security posture, because a compromised KDC nullifies the effect of all other controls and undermines trust in identities.

ISO/IEC 27001:2022 does not mention Kerberos by name, but requires secure authentication and monitoring in Annex A.8.5 and A.8.16. When an auditor extends your scope to Active Directory, they check the implementation against the 93 controls. According to Section 30 NIS2UmsuCG, the NIS 2 implementation in Germany requires technical and organisational measures that correspond to the state of the art. The BSI basic protection specifies this in the building blocks APP.2.2 Active Directory and ORP.4 Identity and authorisation management, including requirements for krb5 configurations, KRBTGT password rotation and ticket encryption. The insurance supervision VAIT, the banking supervision BAIT and the supervision of payment service providers ZAIT also refer to comparable requirements.

This means that there are three to four frameworks on top of each other, which must be proven separately in the audit. A single configuration screenshot is not enough. Auditors expect an inventory of domain controllers, documented hardening with version status, reports from the vulnerability scanner and an explanation as to why certain legacy configurations are permitted differently. The chain of evidence must be consistent over time, i.e. the hardening decision, implementation date and effectiveness test must build on one another. Anyone who dates a measure retroactively risks findings at the major level and even the certification being revoked.

The auditor calls, the evidence is ready. In the CIVAC workspace, you link ISO controls, NIS 2 measures and BSI building blocks with the same documents so that Kerberos hardening is documented in all three frameworks at the same time. This saves duplication of work and reduces inconsistencies that auditors immediately notice. A consolidated evidence matrix shortens typical audit days by around twenty percent because queries become less frequent and samples can be answered more quickly. Audit-proof, documented, Section 30-proof. Anyone who audits for VAIT, BAIT or ZAIT can use the same document matrix and thus serve three regulatory lines at the same time, without having to maintain documents in parallel or compare versions.

Kerberoasting uses service principal names to request encrypted tickets from Active Directory and break against dictionaries offline. If a service account is identified with a weak password, an attacker can take over its identity. Golden ticket attacks require the KRBTGT account to be compromised and allow arbitrary tickets to be issued without domain controller involvement. Silver Tickets falsify service tickets against individual services and bypass the KDC entirely. All three attack classes have been publicly documented for years, implemented in open source tools such as Rubeus, Mimikatz and Impacket and are part of the standard repertoire of every red team engagement.

For compliance this means: three risk scenarios must be explicitly addressed. Firstly, you need a documented service account hardening program with password lengths of at least 25 characters and group managed service accounts where technically possible. Secondly, the KRBTGT password must be rotated twice at defined intervals, usually 180 days or ad hoc after suspected compromise. Thirdly, you need a detection concept that makes unusual ticket requests visible, such as mass TGS-REQ packages or tickets with excessively long validity periods. This detection must be stored in the SIEM with rules, threshold values ​​and escalation paths.

These measures are mapped in the CIVAC workspace as control targets with measurement and review cycles. The external information security officer documents detection rules, threshold values ​​and escalation paths in the same system in which the NIS-2 incident reporting path is anchored. The appointment certificate, signed, filed, verifiable. The risk is not only treated technically, but also verifiable organizationally, so that the effectiveness of a detection rule can be proven in the audit using real alerts and their processing. In addition, an annual red team exercise with the explicit aim of testing Kerberoasting and golden ticket scenarios is recommended, the results of which in turn flow into the risk register and demonstrate the effectiveness of the existing controls.

A typical ISO 27001 Kerberos hardening audit takes between four and eight hours, depending on the domain structure and subsidiaries. Inspectors work through a checklist that is divided into four areas. First, configuration evidence: current group policy exports to Kerberos policies, encryption types and maximum lifetimes. Second, proof of identity: inventory of privileged accounts, separation of day work accounts and admin accounts, service account list with responsible person. Third, operational documents: tickets from change management documenting KRBTGT rotation and domain controller patches. Fourth, incident evidence: Examples from the SIEM that show that the detection for Kerberoasting is effective and was processed in a reasonable time.

Anyone who goes into the audit without preparation often only provides screenshots without a time stamp. This is not enough because ISO 27001:2022 requires effectiveness tests over time under A.5.36. The documents must therefore show a complete quarterly or annual rhythm, ideally with a link to the risk register. The CIVAC workspace model provides exactly this connection, in which 490 audit templates for authentication, identity management and incident response are ready for use. Each template has fixed fields for responsible person, date, document, follow-up action and review interval.

Audit-proof, documented, ISO-proof. The goal is not a nice presentation, but rather seamless traceability from measure to document to the person responsible. When your auditor takes a sample, the next click should be enough, not a search through distributed folders and SharePoint structures. In practice, this speed determines whether an audit day is relaxed or ends with questions, stress and subsequent searches for documents. The discipline lies in daily maintenance, not in the audit weekend. Experienced auditors immediately recognise whether documents are created in day-to-day business or whether they were produced subsequently for audit preparation and weight their samples accordingly.

If a KRBTGT hash is disclosed or a domain controller is compromised, there is a significant security incident according to Section 32 NIS2UmsuCG. Deadline begins as soon as we become aware of it. The early warning to the Federal Office for Information Security must be sent within 24 hours, the follow-up report with the first assessment within 72 hours, and the final report after one month at the latest. These deadlines are independent of whether you have already identified the cause yourself. Anyone who misses the 24-hour deadline risks fines of up to 10 million euros or 2 percent of group sales for essential facilities.

This has concrete consequences for Kerberos incidents. Before the incident, you must have determined who will classify the incident, who will operate the BSI reporting portal and who will manage the operational recovery. A golden ticket situation typically requires a double KRBTGT rotation at short intervals, a domain-wide session termination, and in many cases reissuance of service account passwords. This is a decision with a high degree of impact and must be made by a designated responsible person, not from ongoing day-to-day business. Otherwise there is a risk of contradictory instructions.

The roles, templates and escalation levels are preconfigured in the CIVAC NIS-2 reporting path. The 24-hour and 72-hour reporting windows are stored as tasks with responsible persons, and the workspace automatically sends reminders. This means that incident reporting does not become an improvisation, but rather a routine. A test run once a year uncovers gaps in the accessibility of those responsible and checks whether the report text is technically viable. The sample itself is stored again as evidence in the ISMS and is available in the audit. It is important to coordinate with corporate communications and the legal department because a report to the BSI also has implications for press work and contractual relationships with customers.

Service accounts are historically developed and poorly documented in many environments. These very accounts are the main target of Kerberoasting. An auditable inventory requires at least five fields per account: technical name, technical purpose, service used, password length and person responsible. Group Managed Service Accounts are, where technically possible, preferable to classic service accounts because they rotate automatically and generate 240-character passwords. An inventory without a responsible person is worthless in an audit because no one takes over the maintenance and findings are not processed for years.

Privileged accounts belong in a tier model. Tier 0 is domain administrators, Tier 1 is server administrators, Tier 2 is workstation or help desk accounts. Registration may only take place at the assigned tier level in order to prevent lateral movement. This separation can be technically implemented in the authentication policy and authentication silo mechanism of Active Directory and can be tested for ISO/IEC 27001:2022 Annex A.8.2 (Privileged access rights). A Tier 0 login on a regular workstation is a clear finding in the event of an audit and should be technically prevented.

The documentation belongs in a central system, not in an Excel spreadsheet that no one maintains anymore. In the CIVAC workspace you keep the account inventory as a living register with quarterly reviews. The Compliance Officer and the Information Security Officer work on the same data status and can address findings directly as a measure. Licence the workspace for your internal representatives or have our representatives order it. The register also serves as the basis for risk analysis because each service account is assigned a protection requirement. From this assignment it can be determined which accounts require special hardening, which must be included in privileged access management and which are adequately protected without increased effort.

Kerberos compliance is not an isolated issue. The findings from authentication reviews feed the risk register, influence the security concept and are reflected in the Statement of Applicability. According to clause 6.1.2, ISO/IEC 27001:2022 requires a systematic risk assessment in which vulnerabilities from the authentication area are mapped to business processes. A successful Kerberoasting attack on a service account serving the ERP system is a different incident than an attack on a printer service. This distinction must be visible in the risk model.

This mapping logic must be explicit in the ISMS. Otherwise, there will be no justification as to why certain controls are prioritised. In the CIVAC workspace, the 93 controls of ISO/IEC 27001:2022 are linked to risk assessments, responsible persons and action status. If a pen test reveals a weak service account configuration, the finding can be directly assigned to a control, a risk and a resubmission. The resubmission automatically reminds you of the effectiveness check, so that the finding does not disappear unchecked, but is treated in a closed loop.

The effectiveness check is then not carried out through a separate activity, but by presenting the evidence from ongoing operations. This makes the ISMS come alive instead of just being a folder that is updated once a year for the audit. The appointment certificate, signed, filed, verifiable. This creates compliance that the auditor and the CISO alike enjoy reading because it does not consist of Powerpoint, but of documents. The management can see in the dashboard which residual risks are actively being borne and which measures are effective. This transparency is also a prerequisite for risk acceptance according to ISO 27001, because without a documented decision no residual risk can be assumed by management and the ISMS otherwise remains incomplete.

From practical experience, we can name five findings that regularly appear in Kerberos audits. First: enabled RC4 encryption on service tickets without documented justification. Second: KRBTGT password rotation, which hasn't been done for several years. Third: lack of separation between day-to-day IT work and administration accounts. Fourth: Service accounts with only eight or twelve character password lengths and no rotation concept. Fifth: no detection rule for unusual TGS-REQ patterns. In audits we come across all five, often in combination, which quickly pushes the residual risk assessment into the high range.

Each of these findings is avoidable if the hardening is documented and the ISMS enforces a review cycle. The effort required to fix the problem is manageable: Encryption types can be controlled centrally via group policy, a double KRBTGT rotation costs half a working day, group managed service accounts have been available in Windows Server since 2012, and detection rules are available as public templates for common SIEM systems such as Microsoft Sentinel, Splunk or Elastic. A central patch level for the domain controllers and hardened monitoring of login events complete the picture.

Organizationally anchoring is more difficult. Anyone who implements hardening once and does not check it afterwards has only postponed the audit. Review cycles with those responsible and reminders are stored in the CIVAC workspace, so that the hardening does not remain a one-off project, but rather becomes part of regular operations. The FAQ section answers further practical questions about document chains and audit preparation. It is important to have a clear handover between IT operations and information security so that review results actually flow into the ISMS. A bi-weekly synchronization meeting between domain admin, ISB and compliance is sufficient in most organisations to capture findings early and avoid audit surprises.

CIVAC brings together two ways to achieve Kerberos compliance. Licence the workspace for your internal representatives or have our representatives order it. In the workspace model, your information security officer, your compliance officer and, if applicable, your data protection officer work on a common database. The 490 audit templates, 93 ISO controls and NIS 2 reporting paths are preconfigured and linked to your domain controllers, service accounts and applications. The EU data residency is activated by default, all document uploads remain in Germany.

In the officer-as-a-service model, CIVAC provides you with an external information security officer who checks Kerberos hardening, signs the appointment certificate and is available as a contact person during the audit. The CIVAC SLA for the order is two business days, instead of the industry standard two to six weeks. The representatives work remotely from EU data residences and speak the language of your IT, which significantly speeds up the handover of pen test results and SIEM evaluations. A quarterly reporting line to management is part of the model, supplemented by event-related special reports in the event of critical findings or incidents, so that the supervisory bodies are always aware of the current status.

Turn reading into a mandate. If you want to provide reliable evidence of the Kerberos compliance of your Active Directory or are looking for an external representative to take on the role, write to info@civac.de or use the contact form on civac.de. A short preliminary clarification typically includes the number of domains, number of service accounts and the desired auditing depth, so that the workspace is ready for use within a few days after ordering. We will contact you within one working day with a specific proposal including an appointment for an onboarding discussion. The appointment certificate, signed, filed, verifiable. This turns a regulatory pressure point into an orderly, auditable routine that you can transparently show to your management and auditors.