An attacker with a working credential may find the system already open to them.
That is the uncomfortable reality behind the Cybersecurity and Infrastructure Security Agency’s (CISA) new strategy, “CISA 2030: Defend, Harden, Prevail.” The strategy prioritizes operational technology security, software supply chain integrity and continuity of essential services. It also acknowledges that strong defenses cannot guarantee that intrusions will stop.
Federal agencies face these dependencies in building controls, research facilities and other operational systems. A compromised contractor credential or unverified update can turn an infrastructure problem into a mission disruption.
How much infrastructure still trusts a device, software update or machine identity simply because it was approved once? Meeting CISA’s goals requires examining those approvals, including those no one remembers granting.
Yesterday’s approval becomes today’s exposure
A controller can stay in service for decades while its firmware, credentials, suppliers and connections change around it. A maintenance contractor leaves. A remote connection outlives its purpose. The hardware remains in place. The original reason for trusting it may no longer hold.
An inventory is a starting point. Knowing a controller exists says little about whether its software is authentic, who can change its configuration or which systems depend on its credentials.
Those questions cross organizational boundaries. Device security, software assurance and identity management may each have an owner. If every team owns one piece of trust, who owns the failure between them?
CISA’s goals for operational technology visibility, anomaly detection and supply chain integrity should push operators to answer that question. Someone must be accountable for how devices, code and identities interact throughout their operational lives.
That means verifying software before deployment, protecting signing keys and reassessing access when suppliers or roles change. Even then, authenticity has limits. A valid signature can confirm software origin and integrity. Whether the software is safe for a particular environment is a separate question.
AI turns access into operational authority
That distinction matters more when software can initiate action. Consider an AI agent evaluated for equipment diagnostics and maintenance. Reading diagnostic data and changing an equipment setting carry very different consequences. An authenticated agent with excessive permissions is still a threat to operations.
Before deployment, operators should define which models, tools and data the agent may use, which credentials it can obtain and which actions require human approval. Those restrictions must be enforced when the agent acts. Records should show what it did, whose authority it used and whether required approvals were obtained.
A model’s willingness to follow instructions cannot be the security boundary. Controls should stay consistent when models change or work moves between cloud platforms. Otherwise, each upgrade risks reopening access decisions that security teams thought were settled. Better technology must preserve control over what it can access or change.
Make resilience an acceptance test
Federal technology and acquisition leaders should make those controls a condition of acceptance. Buyers should ask suppliers how they provision device identities, verify updates, retire credentials and help customers recover after a compromise. Contracts should assign responsibility for maintaining those capabilities after deployment.
Investment should follow CISA’s focus on consequences. Which credential could interrupt a federal research facility’s operations? Which signing key could distribute a compromised update across a fleet? Which agent could alter a process affecting worker safety?
Then test whether those permissions can be withdrawn safely.
If withdrawing one compromised credential brings down an essential service, the architecture has failed its resilience test. Exercises should expose those dependencies by testing isolation, credential replacement and restoration of verified software while essential functions continue. Legacy equipment may need compensating controls until it is replaced.
CISA has committed to an implementation and outcome-measurement approach within 180 days. One measure should be whether operators can identify compromised trust, revoke access and restore verified systems while keeping essential services running.
That requires governing trust throughout the life of every device, software component and identity, including AI agents. Approval must come with enforceable limits, continuing verification and a tested way to withdraw it. An agency that cannot safely revoke access remains dependent on the very trust an attacker can exploit. CISA’s strategy will prove its value when operators can break that dependency before it causes an outage.
The post CISA’s new strategy runs into America’s blind trust problem appeared first on CyberScoop.