Notifications
Clear all
Topic starter
10/07/2026 9:09 pm
TL;DR: Traditional MFA is strongest at login, but attacker activity increasingly escalates through trusted internal paths such as admin protocols, legacy systems, and overprivileged service accounts. Zero Networks’ analysis says identity now drives nearly 90% of incidents, while MFA adoption in large enterprises averages 87%. The gap is internal reach, not authentication alone.
NHIMG editorial — based on content published by Zero Networks: What “MFA Everywhere” Misses: Closing the Gap Across Service Accounts, Admin Protocols & Legacy Apps
By the numbers:
- Identity has become the primary attack surface, playing a material role in nearly 90% of cyber incidents.
- MFA adoption rates now average 87% in large enterprises.
- 71% of threat activity flows through four admin protocols: SMB, RDP, WinRM, and RPC.
Questions worth separating out
Q: How should security teams limit lateral movement after MFA login succeeds?
A: Security teams should treat login as the start of governance, not the end.
Q: Why do service accounts create risk even when MFA adoption is high?
A: Service accounts often bypass human authentication workflows and retain broad, persistent access that MFA does not meaningfully govern.
Q: What do security teams get wrong about MFA everywhere?
A: Teams often assume that MFA at the edge protects the whole environment.
Practitioner guidance
- Map post-authentication reach for every identity type Inventory which human, service account, and workload identities can traverse privileged ports, legacy apps, and admin protocols after login.
- Scope service accounts to observed protocol use Reduce machine identity privileges to the exact systems and protocols they actually use in production.
- Remove standing privilege from privileged workflows Replace always-on administrative access with time-bound grants for specific tasks, and require explicit reapproval when the task changes.
What's in the full article
Zero Networks' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how network-layer MFA applies to SMB, RDP, WinRM, and RPC.
- Detailed four-step playbook linking segmentation, JIT access, and protocol enforcement.
- Implementation framing for legacy apps that cannot join modern identity provider flows.
- The vendor's operational view of identity-based microsegmentation and adaptive policy enforcement.
👉 Read Zero Networks' analysis of why MFA everywhere still misses internal identity gaps →
MFA everywhere: what identity teams still miss inside the network?
Explore further
10/07/2026 9:32 pm
Authentication-centric MFA is not the same thing as identity containment. The article correctly exposes a structural weakness in how many programmes define protection at the login boundary and then assume the problem is solved. In NHI terms, service accounts, API-driven workflows, and privileged protocols still need governance after authentication has succeeded. The practitioner conclusion is simple: MFA coverage metrics do not equal containment metrics.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that remediation windows often outlast the attacker’s practical dwell time.
A question worth separating out:
Q: Who is accountable for internal identity reach when MFA is only enforced at login?
A: IAM, PAM, and infrastructure security teams share accountability for internal identity reach because the risk lives between authentication and authorization. If a team can only measure portal login controls, it is not actually governing the full identity path. Accountability should include protocol access, privilege duration, and lateral movement exposure.
👉 Read our full editorial: MFA everywhere still leaves service accounts and protocols exposed
