Zero Trust Implementation: Why the Accounts That Never Expire Are the Real Gap

Zero Trust Implementation: Why the Accounts That Never Expire Are the Real Gap

Zero trust implementation is the process of replacing standing, location-based trust with per-request authentication and authorization for every user, device, and application. Under NIST SP 800-207, it means protecting resources rather than network segments. The practical starting point is an inventory of every account that holds access without a review date, because standing access is the control most implementations skip.

On September 28, 2026, the Department of Defense confirmed that its Defense Manpower Data Center had been breached: Social Security numbers and job details for 2.76 million living people, plus another 294,000 who are deceased, exposed after unauthorized access ran from October 2025 to July 2026 [4]. That is about nine months. The DoD's own statement said a small number of unauthorized users was responsible, and that upon discovery, DMDC immediately remediated the vulnerability [4].

Read that statement again. It is not a perimeter failure story. It is a standing access story. A small number of accounts had access, and nothing re-checked that access for nine months.

That is the failure mode zero trust was written to prevent. The reason most zero trust implementation efforts stall is that they fix the front door and leave the standing access in place.

In our assessments and gap reviews, the accounts with the most standing access are the ones nobody reviews: service accounts, vendor credentials, long-lived OAuth grants. Teams deploy MFA and a zero trust network access gateway, declare the program on track, and move on. But NIST's definition does not hinge on how people get in. It hinges on what is checked before every single access, and that is the part most implementations never build.

Clone Systems' position: most "zero trust" programs are identity-access projects with an architecture label. They change how users authenticate, but they leave standing access untouched, and standing access is exactly what NIST SP 800-207 says zero trust exists to eliminate. The DMDC breach is what that gap costs at scale.

What Does Zero Trust Actually Require, and Why Do Most Implementations Stop Short?

Zero trust requires a discrete authentication and authorization decision before every session to a resource, and implementations stop short because that requirement is a program, not a product purchase.

NIST SP 800-207 defines zero trust as a set of principles that remove implicit trust: no asset or user account is trusted because of its physical or network location, or because of asset ownership, and "Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established" [1]. The emphasis is easy to miss. Trust is not a state you enter. It is a decision made before every session. CISA's own shorthand for the model is two sentences: Never Trust. Always Verify [2].

CISA's zero trust guidance puts it bluntly: ZT principles assume the entire network is compromised [2]. CISA released its Zero Trust Maturity Model in September 2021 as a roadmap for the transition, and published a response to comments in April 2023 summarizing the feedback and the model's modifications, a sign of how hard the transition itself was to execute [2][5].

So why do implementations stop short? Because the first two changes are the easiest to buy. MFA and a ZTNA gateway are products with a procurement path. Discrete, per-request verification of every access is a program: it requires knowing every subject (human, service account, device, application), every resource, and every path between them, and then enforcing policy on each request. That work is not on a product shelf.

The stakes are moving while teams deliberate. In Mandiant's 2026 analysis of more than 500,000 hours of incident investigations in 2025, exploits were the initial infection vector in 32% of intrusions, the sixth consecutive year they have led the list, and voice phishing surged to 11% as the second most common vector [3]. Attackers are getting better at acquiring a valid identity. What protects you is what happens after identity: whether that identity's access is limited, time-boxed, and checked on every use.

Why Was the Pentagon Breach a Zero Trust Failure, Not a Perimeter Failure?

Because it was a standing-access failure: a small number of accounts kept working for about nine months, and no control re-verified that access on any request in between.

The DMDC is one of the Pentagon's main repositories for personnel records, holding more than 60 million records for active-duty and reserve troops, civilian employees, contractors, retirees, veterans, and military family members [4]. The breach exposed Social Security numbers and job details for 2.76 million living people and 294,000 who are deceased [4]. Two details do the analytical work.

First, the duration. About nine months of unauthorized access, discovered in July 2026 [4]. For comparison, Mandiant's global median attacker dwell time in 2025 was 14 days, up from 11, and 122 days in cyber espionage and North Korean IT worker cases [3]. The DMDC window was more than double the espionage median. This is not a gap a better scanner closes. It is the shape of access that was granted, never re-checked, and never time-boxed.

Second, the actor count. A small number of unauthorized users [4]. In a perimeter model, once an account is inside, its movement is governed by network position, and its access persists until someone revokes it. Zero trust inverts the default: authorization is granted per request, for the specific resource, and it expires [1]. Under that model, the nine-month window closes by itself. An account whose authorization lapses stops working even if the attacker keeps the credential.

The DoD said it has found no evidence yet that the exposed data has been misused, and it is offering identity protection and credit monitoring [4]. That is the good news. The rest is the lesson: the breach was not a single bad day. It was a default setting.

Zero Trust vs Network Segmentation: What Is the Difference?

Segmentation controls whether traffic crosses a network boundary. Zero trust controls whether a specific subject, with a specific identity, on a specific device, may access a specific resource right now. They are related, but one is a building block and the other is the building.

NIST draws the line: zero trust focuses on "protecting resources (assets, services, workflows, network accounts, etc.), not network segments" [1]. CISA describes the shift as moving "from a location-centric to a data-centric adaptive approach" [2]. Segmentation asks whether traffic may cross that boundary. Zero trust asks whether this subject, on this device, may reach this resource, this time.

CISA's implementation guidance treats microsegmentation as one part of the zero trust transition, not the transition itself [2]. Segmentation is a building block of zero trust, the way a firewall is a building block of a perimeter. Doing the building block and calling it the building is the most common error we see in zero trust implementation plans.

Where Should Zero Trust Implementation Start?

Start with the standing access inventory, not with a platform purchase. The DMDC breach shows the cost of never asking the question [4], and Mandiant's 2025 data shows why the sequencing matters: the mean time to exploit a vulnerability dropped to an estimated minus 7 days, meaning exploitation now routinely happens before a patch is released [3].

The Clone Systems 6-Point Standing Access Audit is the sequence we use to establish the baseline:

1. Service accounts and credentials with no expiry. Every non-human identity: applications, integrations, scripts, monitoring tools. For each one, record the owner, the last use, and an expiry date. In our reviews, the oldest active credential is almost always older than the policy says it should be, and it almost always has no named owner. The same pattern shows up in AI systems, where a workflow service account can keep executing long after the project that created it has ended AI Agent Authorization: Why Your Workflow's Service Account Is the Attack Surface.
2. Third-party and vendor access. Remote support credentials, contractor accounts, shared credentials with SaaS vendors. If your vendor's access cannot be shown with a review date, treat it as unreviewed. The same logic applies to the paperwork: a clean vendor questionnaire is not evidence of what a vendor's accounts can actually do Why a Clean Vendor Security Questionnaire Doesn't Mean Your Vendor Is Patched.
3. OAuth app grants and API tokens. The integrations your team approved two years ago, still holding broad scopes. Mandiant documented attackers harvesting long-lived OAuth tokens and session cookies to pivot into SaaS environments [3].
4. Standing administrative rights. Local admin, domain admin, cloud admin, database admin. Zero trust does not ban admins. It makes admin a request, not a state [1].
5. Device trust that outlives identity. Certificates, legacy protocols, edge appliances that bypass MFA entirely. Mandiant tracked espionage clusters that target exactly these devices, with one in-memory backdoor persisting for roughly 400 days, far beyond the 90-day log retention window that would have caught it [3].
6. Access reviews that exist. A review date and a named owner for every item above. If there is no review, the access is permanent by default, which is the opposite of zero trust.

Then sequence the architecture work around the baseline: least privilege and time-boxed access first, continuous verification of identity and device second, microsegmentation where the audit shows movement actually matters, and the telemetry to see all of it [2][3]. If you are not monitoring what you re-architect, you cannot tell whether the change worked. Organizations now first detect malicious activity internally 52% of the time, up from 43% in 2024 [3], which is where the detection dividend from zero trust shows up How to Choose a Managed SOC Provider.

Test your own environment. Three questions:

1. Can you name every account in your environment that never expires?
2. What is the oldest active credential you can find, and who approved it?
3. Which of your vendor or service accounts can reach your most sensitive data without MFA?

If any of the three takes more than a day to answer, you have your zero trust project scope, and your answer to the next board question about why the roadmap starts with an identity cleanup rather than a platform purchase.

If you are drafting that roadmap and want a second set of eyes on the standing access baseline, contact our team. We run the 6-Point Standing Access Audit as a scoped engagement and will tell you honestly where the baseline is thin.

How Clone Systems Can Help

Clone Systems helps with zero trust the way we evaluate it: from the standing access baseline outward, not from a platform purchase inward.

• Zero trust readiness assessment. We run the 6-Point Standing Access Audit across your identity, vendor, and SaaS estate, and map the result against NIST SP 800-207 and CISA's maturity model, so the roadmap starts from evidence rather than a vendor deck Contact.
• Penetration testing of the access paths the audit flags. Standing access only matters if it can be exploited. A test demonstrates what a compromised service account or vendor credential can actually reach Managed Penetration Testing.
• Managed SOC and SIEM. Zero trust generates the telemetry that makes per-request decisions and exposes standing access being abused. Our managed SOC monitors that flow with AI-assisted triage, and the pricing is published Managed SOC service.

Frequently Asked Questions

What is zero trust architecture? Zero trust architecture is a set of security principles in which no user, device, or system is trusted by default, and every access request is authenticated and authorized before a session is established. NIST formalized the model in SP 800-207, and CISA publishes the Zero Trust Maturity Model as a transition roadmap.

Where do I start with zero trust implementation? Start with an inventory of standing access: service accounts, vendor credentials, OAuth grants, standing admin rights, and device trust that bypasses identity checks. The 6-Point Standing Access Audit in this post is the sequence we use, because every framework begins with knowing which subjects hold access.

Is zero trust the same as network segmentation? No. Segmentation controls whether traffic crosses a network boundary, while zero trust verifies the identity, device, and authorization of every request to a resource regardless of location. NIST states that zero trust protects resources, not network segments, and CISA treats microsegmentation as one part of a broader transition.

Does zero trust require buying a new platform? No, although identity platforms, ZTNA gateways, and SASE solutions are common components. The requirement is behavioral: discrete per-request verification and least privilege, which you can begin to enforce with existing identity, access review, and monitoring controls.

How long does zero trust implementation take? There is no fixed timeline, because zero trust is a transition of access decisions rather than a product installation. CISA frames the transition as a maturity roadmap, and in our engagements the teams that sequence identity and access changes before network work see the first benefits within a quarter.

Conclusion

The perimeter model granted trust once and never asked again. The DMDC breach is what that default looks like at national scale [4], and Mandiant's 2025 data shows the attacker timeline is not waiting for your roadmap to mature [3]. The fix is not a larger wall or a newer gateway. It is a list of every account that holds access, a review date on each one, and a control that verifies every request. Run the 6-Point Standing Access Audit, sequence the changes around it, and start zero trust where the real gap is: the access you already granted. Start at www.clone-systems.com.

References

[1] NIST: SP 800-207, Zero Trust Architecture (Rose, Borchert, Mitchell, Connelly), August 2020. https://csrc.nist.gov/pubs/sp/800/207/final [2] CISA: Zero Trust, topic page (references the September 2021 release of the Zero Trust Maturity Model and implementation guidance including Microsegmentation in Zero Trust). https://www.cisa.gov/topics/cybersecurity-best-practices/zero-trust [3] Mandiant (Google Cloud): "M-Trends 2026: Data, Insights, and Strategies From the Frontlines," March 23, 2026 (full report is a PDF; figures from Mandiant's own HTML summary page). https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026 [4] ABC News: "Pentagon breach exposed sensitive data on nearly 3 million people," September 28, 2026. https://abcnews.com/Politics/pentagon-breach-exposed-sensitive-data-3-million-people/story?id=136832909 [5] CISA: Zero Trust Maturity Model Response to Comments, April 11, 2023. https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model-response-comments [6] Clone Systems: In our assessments and gap reviews, the accounts with the most standing access are the ones nobody reviews, and the oldest active credentials we find are almost always older than policy allows and have no named owner. [7] Clone Systems: AI Agent Authorization: Why Your Workflow's Service Account Is the Attack Surface. www.clone-systems.com/blog/ai-agent-authorization-why-your-workflows-service-account-is-the-attack-surface [8] Clone Systems: Why a Clean Vendor Security Questionnaire Doesn't Mean Your Vendor Is Patched. www.clone-systems.com/blog/why-a-clean-vendor-security-questionnaire-doesnt-mean-your-vendor-is-patched [9] Clone Systems: How to Choose a Managed SOC Provider: The 7 Questions That Separate Coverage From Capability. www.clone-systems.com/blog/how-to-choose-a-managed-soc-provider [10] Clone Systems: Managed Penetration Testing Services. www.clone-systems.com/managed-penetration-testing-services [11] Clone Systems: Managed SOC service. www.clone-systems.com/managed-soc-service [12] Clone Systems: Contact and consultation. www.clone-systems.com/contact