Implementing rate-limiting and account lockout policies is often seen as a straightforward way to protect systems from brute-force attacks. Once these controls are in place, many teams consider the problem solved. Auditors seldom challenge this, and frameworks often list it as a simple requirement. The assumption is that any rate-limiting is better than none.
However, the vulnerability CVE-2026-16347, affecting all versions of MikroTik RouterOS and Cloud Hosted Router, reveals the flaws in this checkbox mentality. Despite implementing rate-limiting with a per-connection delay, attackers bypassed it by opening concurrent sessions. The rate-limit was there, but it didn't effectively limit authentication attempts across the system.
Why Rate-Limiting Alone Isn't Enough
The issue isn't that rate-limiting is ineffective; it's that it's often reduced to a simple yes-or-no question. Did you add rate-limiting? Yes. Control implemented. This overlooks three critical aspects:
First, consider attack vectors, not just feature implementation. A per-connection delay might stop a single attacker using one session, but it won't stop an attacker who can parallelize their attempts. If your rate-limit can be bypassed by opening multiple connections, you're not truly limiting the attack surface.
Second, authentication controls need multiple layers. The MikroTik vulnerability shows the danger of relying on a single control. Even if per-connection throttling worked perfectly, where are the source IP blocking, account-level lockout, and anomaly detection for coordinated failures across sessions?
Third, effective implementation matters. ISO/IEC 27002 Control 5.17 and NIST SP 800-53 IA-5 cover authentication management, but they won't tell you if your rate-limiting can be bypassed through concurrent sessions. You need to model threats specific to your architecture.
Evidence of the Problem
The MikroTik case isn't unique. It's an example of how authentication controls can fail in real environments.
The vulnerability allows attackers with network access to make rapid password guesses against administrative services. The system's defensive mechanism is based on an incorrect threat model, assuming attackers will use one connection at a time.
CISA's guidance on this vulnerability highlights minimizing network exposure and using defense-in-depth strategies. This acknowledges the real issue: no single authentication control is enough. The lack of reported public exploitation doesn't mean it's not happening; it means detection is tough when authentication logging doesn't correlate attempts across sessions.
The CVSS vector (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) indicates that while network access is required, the attack complexity is low. If an attacker is on your network, your authentication controls must work under concurrent load. A per-connection delay doesn't meet this requirement.
What to Do Instead
Stop asking "Did we implement rate-limiting?" Start asking "Can an attacker exceed our intended authentication attempt threshold by any means?"
Implement rate-limiting at multiple enforcement points:
- Per source IP address, not just per connection
- Per target account, regardless of source
- Per time window at the service level (total authentication attempts to the service)
For network devices, configure your firewall or access control lists to enforce connection rate limits before traffic reaches the device's authentication service. If your router's API can be overwhelmed by concurrent sessions, the router shouldn't be the only enforcement point.
Test your authentication controls against realistic attack patterns. Simulate an attacker opening multiple sessions and verify that your cumulative rate across all sessions stays within acceptable bounds. If you can't measure cross-session authentication rates, you can't defend against cross-session attacks.
Instrument authentication failures with correlation in mind. Your logs should easily show: "How many authentication failures occurred against this device from all sources in the last minute?" If this requires manual log parsing, your monitoring isn't adequate.
For critical infrastructure devices, consider Zero Trust Architecture principles. Network adjacency shouldn't grant authentication attempts. If your router API is exposed to any untrusted network segment, you need network-level access controls to prevent unauthenticated devices from reaching the authentication service.
When Conventional Wisdom Applies
Rate-limiting and account lockout mechanisms are essential controls. The conventional wisdom isn't wrong; it's just incomplete.
Simple rate-limiting works well when:
- You're defending against unsophisticated attackers who won't parallelize their attempts
- The service architecture makes concurrent session attacks impractical
- You've implemented complementary controls (source blocking, account lockout, anomaly detection) to catch what rate-limiting misses
Account lockout policies are effective when you can tolerate the availability impact. For administrative interfaces on network devices, temporarily locking an account after failed attempts is often acceptable. For customer-facing services, it's a denial-of-service risk.
Frameworks like ISO/IEC 27001 Annex A 5.17 and NIST Cybersecurity Framework PR.AC-1 correctly identify authentication as a foundational control. The issue isn't whether to implement these controls; it's recognizing that quality matters more than existence.
If you're responsible for network device security, don't wait for your vendor to patch authentication handling. Review your current controls with this question: "If an attacker opens twenty concurrent sessions to this device, what's the maximum authentication attempt rate they can achieve?" If the answer is "I don't know" or "unlimited," you have work to do.
The checkbox says you implemented rate-limiting. The attacker doesn't care what the checkbox says.
