The BSI Abolished Mandatory Password Changes — But Only Under One Condition

What ORP.4.A23 actually requires — and why compromise detection is not optional, but a prerequisite.

The Question That Changes Everything

An information security officer returns from an ISMS audit. The external auditor had reviewed the password policy and noted approvingly that the organization had dropped forced password rotation — in line with current BSI recommendations. But then came the follow-up question:

The room went quiet. Because the honest answer was: they didn't know. They had removed the old control without implementing the new one. And that gap is not a minor oversight — it is a compliance violation of a mandatory BSI requirement.

What ORP.4.A23 Actually Says

In 2020, the German Federal Office for Information Security (BSI) fundamentally changed its position on password rotation in the IT-Grundschutz-Kompendium. The relevant requirement, ORP.4.A23 ("Regulations for password quality and handling"), states:

Three sentences. Two levels of obligation. And everything hinges on the last one.

In BSI methodology, the word "SHOULD" indicates a recommendation that can be deviated from with justification. The word "MUST," however, designates a binding requirement — a control that has to be implemented unless extraordinary circumstances make it demonstrably impossible. There is no wiggle room.

This means the BSI did not simply give organizations a free pass to stop changing passwords. It conditionally abolished mandatory rotation — and the condition is the obligation to detect password compromises through active measures. Drop the rotation without implementing compromise detection, and you are not following the BSI recommendation. You are violating it.

Why the BSI Changed Course

The reasoning behind the change is well-documented and widely supported by security research. Forced password rotation at fixed intervals — every 90 days being the classic — leads to predictable user behavior:

• Sequential patterns: Summer2024! becomes Summer2025!
• Minimal character substitution to satisfy change requirements
• Passwords written on sticky notes because they change too frequently to memorize
• Increased help desk load from forgotten passwords after each rotation

The security gain from forced rotation is marginal at best. A strong, unique password that has not been compromised can remain secure for years. Forcing a change every quarter does not make it more secure — it makes it weaker, because users optimize for memorability over entropy.

The BSI's new logic is straightforward: change a password when there is a concrete reason to do so — specifically, when there is evidence of compromise. That is the "valid reason" referenced in ORP.4.A23. And detecting that reason requires a mechanism, not hope.

The Half-Measure — And Why It Falls Short

Many organizations believe they already have compromise detection covered. The most common approaches:

• Have I Been Pwned (HIBP) checks at password creation: The password is compared against a database of known breached passwords when the user sets it.
• Microsoft Entra Password Protection: Blocks passwords that appear on breach lists or match common patterns during password set or reset.
• Internal banned-password lists: Custom lists maintained by the IT team.

These are point-in-time checks. They answer the question: "Is this password generically known to be compromised at the moment it is being created?" That is a valid and useful control — but it does not fulfill the requirement in ORP.4.A23.

Here is the scenario these controls miss entirely: An employee sets a strong, unique password. It passes every check. Six months later, the employee's device is infected with an infostealer — RedLine, Raccoon, Lumma. The malware harvests all saved credentials from the browser, including the corporate password. Those credentials are sold on a dark web marketplace within days.

The password was strong. It was unique. It passed every list check. And it is now in the hands of an attacker. A point-in-time check at creation will never catch this. The password was not generically "bad" — it was specifically stolen.

Where Dark Web Monitoring Closes the Gap

This is the fundamental difference between a point-in-time check and continuous Dark Web Monitoring. The former asks: "Is this password on a list right now?" The latter asks: "Are the specific credentials of this specific organization circulating on the dark web — right now, or since the last check?"

A robust dark web monitoring service continuously scans:

• Infostealer logs: Credentials harvested from compromised endpoints, often including the exact URL, username, and password in plaintext
• Credential dump marketplaces: Structured databases of stolen login data, sold in bulk or per entry
• Paste sites and dark web forums: Where compromised data is shared, traded, or leaked
• Combo lists: Aggregated credential collections used for credential stuffing attacks

When a match is found — corporate email address plus password, or corporate domain in an infostealer log — the monitoring triggers an alert. That alert is the "valid reason" the BSI requires. It provides the concrete evidence that a specific password has been compromised and needs to be changed.

With webhook or SIEM integration, the process can be partially automated: a compromised credential triggers a targeted password reset for the affected account, without disrupting the entire organization with a blanket rotation policy.

The Honest Part: Dark Web Monitoring Is Early Warning, Not Full Protection

No responsible provider should claim that dark web monitoring detects every compromise in real time. There is structural latency in the system:

• A credential is stolen by an infostealer. It may take hours to days before it appears on a marketplace.
• It may be sold privately before it surfaces on monitored channels.
• Some stolen data never reaches the public or semi-public dark web — it is used directly.

This means dark web monitoring is an early warning system, not an impenetrable shield. It significantly reduces the window between compromise and detection — from "never" or "months later during an incident" to "days or weeks." That reduction matters. In many documented breaches, the attackers had access for months before anyone noticed.

A multi-provider approach improves coverage: different monitoring services have access to different sources, forums, and marketplaces. No single provider sees everything. Additionally, brand mention monitoring — tracking where your company name, domains, or executive identities appear on the dark web — serves as a second detection layer, catching impersonation attempts and targeted attack planning that pure credential matching would miss.

Why This Matters for Compliance Documentation

ORP.4.A23 does not just require that compromise detection exists — it requires documented measures. In an audit context, the question is not "do you detect compromised passwords?" but "show me how you detect compromised passwords, and show me the evidence."

A dark web monitoring service produces exactly the kind of documentation auditors look for:

• Regular reports: What was scanned, what was found, what actions were taken
• Alert logs: Timestamped records of compromised credentials detected
• Response documentation: Evidence that affected passwords were changed after detection
• Coverage scope: Which domains, email addresses, and data types are monitored

This aligns directly with NIS-2 Directive requirements as well. Article 21 of NIS-2 mandates that essential and important entities implement "policies and procedures to assess the effectiveness of cybersecurity risk-management measures." Dark web monitoring provides both the risk detection mechanism and the audit trail that demonstrates its effectiveness.

For organizations operating under both IT-Grundschutz and NIS-2, a documented dark web monitoring process satisfies requirements on both sides — making it one of the more efficient controls in terms of compliance coverage per implementation effort.

Conclusion

The BSI's position on password rotation is correct — and widely misunderstood. The headline "no more forced password changes" has traveled far. The condition attached to it has not traveled far enough.

ORP.4.A23 is clear: dropping forced rotation is only permissible if you can detect when a password has been compromised. Without that detection capability, removing scheduled password changes does not modernize your security posture — it weakens it. You have removed the old safety net without deploying the new one.

Dark web monitoring is not the only component of a mature credential security strategy. But it is the component most organizations are missing — and the one that ORP.4.A23 explicitly demands.

Find Out What Attackers Already Know

We provide organizations with a free Dark Web Report covering the past 24 months — showing which corporate credentials, if any, are actively circulating on dark web marketplaces, infostealer logs, and credential dumps.

Request your free Dark Web Report now — and close the gap that ORP.4.A23 requires you to close.