Which teams are accountable for identity hardening under EO 14028?

How EO 14028 Splits Identity Hardening Across Teams

Identity hardening under EO 14028 is not owned by a single function because the work spans policy, technical controls, procurement, and supplier oversight. Security sets the bar, IAM implements authentication and access patterns, engineering changes the systems that use those controls, procurement enforces requirements on suppliers, and vendor management keeps third parties accountable.

That split matters because the order’s intent is not just stronger login controls. It also pushes agencies and vendors toward better software assurance, safer defaults, and more disciplined reporting when identity-related weaknesses show up in production or in the supply chain.

A useful way to think about ownership is by control plane: security defines the standard, IAM operationalises identity controls, engineering integrates them into applications and platforms, and procurement or vendor management makes sure external products and services can actually meet the requirement. If one team treats the order as “someone else’s problem”, hardening becomes uneven and easy to bypass.

Why Identity Hardening Under EO 14028 Is a Shared Governance Problem

EO 14028 creates overlap by design. Authentication is a security concern, but it is also an architecture concern when services, APIs, admin paths, and build systems must be changed to support stronger identity checks. Procurement becomes involved because the organisation may need contract language, attestations, or product requirements to avoid buying tools that cannot support the mandated controls.

That shared responsibility is normal for enterprise hardening. The practical issue is making sure each team owns the part it can actually change. Security can define control intent and exceptions, IAM can manage identity lifecycle and privileged access patterns, engineering can remove brittle legacy flows, and vendor management can prevent third parties from creating weak links in the chain.

For programme design, the key question is not “who is the lead?” but “who can block failure at each layer?”. In hardening programmes, the answer usually includes policy owners, control operators, system owners, and supplier owners working together rather than in sequence.

What Teams Need to Coordinate to Avoid Fragmented Ownership

Fragmentation usually appears in four places. First, security writes requirements that IAM cannot fully deploy because application owners have not been engaged. Second, engineering ships integrations that bypass approved authentication patterns for convenience. Third, procurement signs off vendors without checking whether identity requirements are contractually enforceable. Fourth, vendor management assumes a supplier’s assurance claims are enough without testing the actual control fit.

The strongest programmes make ownership explicit at the level of outcome, not just task. Security owns policy and risk acceptance, IAM owns identity controls and lifecycle operations, engineering owns implementation in products and pipelines, and procurement or vendor management owns the external dependency chain. That is how you prevent identity hardening from collapsing into disconnected checklists.

This is also where software provenance and incident reporting become relevant. EO 14028 links identity hardening to broader assurance expectations, so teams need to be able to trace who approved a control, who implemented it, and who is responsible when a supplier or product cannot meet the required standard. Without that traceability, accountability becomes purely rhetorical.

Risk and Threat Considerations

When identity hardening is split across multiple teams without a clear ownership model, the common failure is not total absence of controls, it is inconsistent enforcement. Attackers benefit from that inconsistency because they look for the weakest path, especially where authentication, privileged access, or supplier access is handled differently across environments.

Failure mechanism: A control may be defined centrally but left partially implemented in applications, vendor products, or procurement contracts, creating gaps that allow weak authentication, overbroad access, or supplier-driven exceptions to persist.

Impact: The organisation can end up with uneven assurance, harder incident response, and a larger blast radius when a compromised account, vulnerable product, or weak third-party integration is abused.

Practitioner Guidance

What to verify: Confirm that every identity-hardening requirement has a named control owner, an implementation owner, and a supplier owner where third parties are involved. If any one of those roles is missing, the programme is not yet operationally complete.

Ownership: Treat security as the policy and risk authority, IAM as the control operator, engineering as the system integrator, and procurement or vendor management as the external enforcement layer. That division prevents each team from assuming another team will close the gap.

Common mistake: Do not let the programme become a “login upgrade” project. EO 14028-related hardening fails when teams focus only on authentication mechanics and ignore vendor terms, implementation debt, and incident accountability.

Practitioner takeaway: Identity hardening works only when the organisation assigns control, implementation, and supplier accountability together, because EO 14028 exposure is created as much by coordination failure as by weak authentication.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?