Executive Order 14028 pushes zero trust and identity hardening

At a glance

What this is: Axiad’s post explains how Executive Order 14028 accelerates zero trust, software supply chain scrutiny, and stronger identity controls across federal and contractor environments.

Why it matters: It matters because IAM, NHI, and PAM programmes will be judged against broader security and disclosure expectations, not just login hygiene.

By the numbers:

• The executive order leverages the federal government's $70 billion IT budget to encourage better security practices.
• The Biden administration wants to leverage the federal government's $70 billion IT budget to encourage better security practices.

👉 Read Axiad's analysis of Executive Order 14028 and zero trust identity controls

Context

Executive Order 14028 frames cybersecurity as a governance problem as much as a technical one. The primary keyword here is zero trust, but the deeper issue is identity assurance across users, systems, and suppliers.

For IAM teams, the important shift is that authentication, software provenance, and incident disclosure now intersect. That means identity controls can no longer be treated as a front-door issue while supplier trust and response playbooks sit elsewhere in the programme.

Key questions

Q: How should security teams apply zero trust to identity governance?

A: They should treat trust as conditional and continuously reassessed. That means stronger authentication, resource-sensitive access decisions, and tighter oversight of suppliers and software paths, not just perimeter controls. The goal is to reduce reliance on static trust signals and make access proportional to the risk of the resource being reached.

Q: Why does Executive Order 14028 matter for IAM teams?

A: It expands identity from login management into broader governance. IAM teams need to account for authentication, incident disclosure, software provenance, and supplier access because those controls now shape how resilient the organisation is under attack.

Q: What breaks when identity controls stop at MFA and passwords?

A: The programme can still miss the identities and relationships that matter most, including service providers, software suppliers, and the access paths built into delivery pipelines. Strong login controls are useful, but they do not by themselves prove who can change systems, ship code, or disclose incidents.

Q: Who is accountable when supplier access and cyber incidents overlap?

A: Accountability sits with the organisation that owns the system and its governance, even when a contractor or software provider is involved. That means contract terms, review cycles, and response playbooks must clearly assign ownership for access, disclosure, and revocation duties.

Technical breakdown

Zero trust architecture and identity verification

The article treats zero trust as a model that assumes compromise may already exist and therefore requires verification before access is granted. In practice, that means identities are not trusted because they are on the network or inside the perimeter. Access decisions must be continually re-evaluated using stronger authentication, context, and least privilege. For identity teams, the technical consequence is that authentication becomes a continuous control surface, not a one-time login event.

Practical implication: align access policy, MFA, and step-up checks to resource sensitivity instead of relying on session-long trust.

Software supply chain security and provenance

EO 14028 also pushes security into software development and acquisition. The article’s message is that organisations must know where code comes from, what is being shipped, and which vendors are accountable when incidents occur. That makes source integrity, contract requirements, and release transparency part of identity governance because software supply chains carry the credentials, tokens, and trust relationships that identity systems depend on.

Practical implication: map supplier access and software provenance into third-party governance before the next contract renewal.

Incident disclosure and response playbooks

The updated playbooks described in the article matter because standardised response reduces ambiguity when cyber events occur. A playbook gives agencies a repeatable sequence for triage, correction, and reporting, which helps prevent gaps in ownership. For identity programmes, this is a reminder that recovery is not only about systems coming back online. It is also about knowing which identities, keys, and access paths were involved.

Practical implication: connect incident response runbooks to identity revocation, credential review, and supplier notification steps.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero trust is now an identity governance mandate, not a network slogan. EO 14028 reinforces the idea that trust must be proportional to verification, which pushes identity controls into every access decision. That widens the scope of IAM from authentication into continuous assurance across users, workloads, and suppliers. Practitioners should treat this as a governance reset, not a perimeter rebrand.

Software supply chain security is an identity problem because software carries trust relationships. When organisations cannot verify code origin, contractor obligations, and incident reporting duties, they cannot fully govern the identities and secrets that travel with that software. The article makes clear that supplier scrutiny will deepen, so contract language and access reviews need to evolve together. Practitioners should fold vendor trust into identity risk management.

Identity programmes that stop at the login screen will miss the control plane that EO 14028 targets. Passwords, MFA, and device checks matter, but the order also points to disclosure, response, and software provenance as part of resilience. That is a broader operating model than many IAM teams currently own. Practitioners should reframe identity as part of cyber governance, not a standalone service.

Zero trust authentication assumes attackers can intercept or reuse static credentials, which is why it favours stronger, context-aware verification. The article’s emphasis on passwords and push messages reflects a familiar failure mode: a credential alone is not a durable trust signal. That has direct implications for NHI and human access alike. Practitioners should reduce dependence on reusable authentication factors wherever possible.

Identity attack surface: The executive order pushes organisations to reduce how much trust is exposed across users, suppliers, and software paths at once. That matters because attack surface is no longer only about exposed endpoints or weak passwords. It includes the identities, entitlements, and external dependencies that can be abused under pressure. Practitioners should treat attack surface reduction as a cross-domain identity objective.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why identity-led zero trust still breaks at the operational layer.
• That visibility gap is explored further in Top 10 NHI Issues, where unmanaged machine identities and over-privilege remain recurring control failures.

What this signals

Zero trust will keep failing if teams treat identity as a front-end problem only. EO 14028 effectively widens the governance boundary to include suppliers, release processes, and incident disclosure. For practitioners, that means IAM, procurement, and response planning need to be managed as one control system rather than separate workstreams.

Identity attack surface is the better organising concept for this shift. When organisations reduce static trust across login flows, software provenance, and third-party access, they shrink the number of places an adversary can turn trust into compromise. That framing is useful across human identity, NHI, and workload access because the same governance failure can appear in different forms.

The practical signal is that zero trust programmes should now be measured by how quickly they can identify, verify, and revoke trust relationships across internal and external actors. If that cannot happen, the organisation still has hidden trust debt.

For practitioners

• Rework access policies around verification, not session trust. Move critical applications toward step-up authentication and sensitivity-based controls so access is re-evaluated when risk changes, rather than assumed for the life of a session.
• Map supplier access into third-party identity governance. Inventory which contractors, software providers, and service partners can reach sensitive systems, then tie those relationships to contract terms, access reviews, and offboarding.
• Tie incident response to identity revocation. Update playbooks so every cyber event triggers checks for exposed credentials, token revocation, access path review, and evidence preservation before normal operations resume.
• Treat software provenance as part of trust management. Require teams to document code origin, release ownership, and vendor reporting obligations so supply chain trust is visible when procurement or incident review happens.

Key takeaways

• EO 14028 broadens cybersecurity from authentication into governance, disclosure, and software provenance.
• The practical burden shifts to reducing identity attack surface across users, suppliers, and code delivery paths.
• Teams that separate IAM from incident response and vendor oversight will struggle to meet the intent of the order.

Key terms

• Zero Trust Architecture: A security model that assumes trust must be earned continuously rather than granted once at login. In identity programmes, it requires verification of user, device, and context before access is allowed, with decisions tied to resource sensitivity and risk rather than network location.
• Identity Attack Surface: The full set of identities, credentials, entitlements, and trust relationships that an attacker could abuse. In practice, it includes human accounts, service accounts, software suppliers, and the access paths embedded in delivery pipelines and response processes.
• Software Supply Chain Security: The discipline of verifying where software comes from, who is responsible for it, and what trust it carries into the environment. For identity teams, this means vendor access, code provenance, and release accountability all belong inside governance, not outside it.

Deepen your knowledge

Zero trust architecture and identity verification are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme that now has to account for supplier trust and software provenance, it is worth exploring.

This post draws on content published by Axiad: Understanding the Executive Order on Improving the Nation's Cybersecurity. Read the original.