Executive Order 14412: The Post-Quantum Deadline Clock Has Started for Every Enterprise

by hannahadmin | Sep 16, 2026 | blog, Quantum Security, Seimless

On June 22, 2026, the White House signed Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks. That order turned post-quantum cryptography from a research topic into a compliance deadline. Under Executive Order 14412, federal high value assets must use quantum-resistant key establishment by December 31, 2030 and quantum-resistant digital signatures by December 31, 2031. Federal contractors come next. The first big milestone, implementation guidance from the Office of Management and Budget, falls due on or about September 20, 2026, 90 days after signing.

For more than 20 years, ibm/SEIMless has helped organizations build networks that protect people as well as data: patients, account holders, policyholders and employees who trust us with their information. Our view is that a quantum deadline is really a promise to those people. This guide explains what Executive Order 14412 requires, who it reaches beyond federal agencies, and what your organization can do in the next 270 days to get ahead of it.

QUICK ANSWER

What is Executive Order 14412? Executive Order 14412 is a U.S. presidential order signed June 22, 2026 (91 FR 38483). It requires federal agencies to move high value assets and high-impact systems to NIST-approved post-quantum cryptography (PQC). Key establishment must be quantum-safe by December 31, 2030 and digital signatures by December 31, 2031. The order also directs the FAR Council to propose a rule requiring covered federal contractors to comply with NIST’s PQC-inclusive FIPS standards by December 31, 2030.

Key Takeaways

For the most sensitive federal systems, the target moves from the 2035 goal to 2030 (encryption) and 2031 (signatures).
Contractors should expect a proposed FAR rule within 180 days of signing (around December 19, 2026), with a 2030 compliance date.
Within 270 days, CISA and NIST are to define minimum elements for a cryptographic bill of materials (CBOM).
Banks, hospitals and insurers are not directly bound, but their regulators, auditors and customers will likely treat Executive Order 14412 as the new benchmark.

Start with data in motion. Traffic captured today can be decrypted once a capable quantum computer exists.

Why Executive Order 14412 Arrived Now

The federal government has been preparing for this moment for years. National Security Memorandum 10 (May 2022) set a goal of mitigating as much quantum risk as feasible by 2035. OMB Memorandum M-23-02 required agencies to inventory quantum-vulnerable cryptography every year. Congress then wrote inventory duties into law with the Quantum Computing Cybersecurity Preparedness Act (Public Law 117-260).

The standards arrived in August 2024. NIST published FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) for digital signatures and FIPS 205 (SLH-DSA) for

hash-based signatures. In March 2025, NIST selected HQC as a backup key-encapsulation algorithm. Its draft NIST IR 8547 proposes deprecating RSA and elliptic-curve algorithms after 2030 and disallowing them after 2035.

The timeline got shorter

Two developments pushed the government to move faster. First, the industry’s own estimates changed. On March 25, 2026, Google announced a 2029 target for its own PQC migration. It pointed to progress in quantum hardware, advances in error correction and new resource estimates for quantum factoring. Second, oversight bodies found gaps. A June 2025 GAO report concluded that the national quantum cybersecurity strategy lacked clear objectives and performance measures.

Behind both sits the threat we have written about in our harvest now, decrypt later analysis: adversaries record encrypted traffic today and wait for the quantum capability to read it. If your data has to stay confidential for ten years or more, it is already at risk. For the math behind that risk, see Shor’s algorithm explained.

What Executive Order 14412 Requires: The Deadline Calendar

The White House fact sheet gives a summary, but the order text sets the milestones. Here they are on one calendar. Dates shown as “on or about” are counted from the June 22, 2026 signing date. Official agency dates may differ.

When	Milestone	Who
On or about Jul 22, 2026 (30 days)	Each agency names a PQC migration lead who reports to the CIO	All agencies
On or about Sep 20, 2026 (90 days)	OMB guidance: agencies review their inventories of high value assets and high-impact systems and submit migration plans	OMB, National Cyber Director, CISA
On or about Dec 19, 2026 (180 days)	NIST starts a PQC pilot on its own systems and speeds up module validation. The FAR Council proposes the contractor compliance rule.	NIST, FAR Council

Jan 1, 2027	New National Security System acquisitions must comply with CNSA 2.0 (a separate NSA track)	NSA / NSS owners
On or about Mar 19, 2027 (270 days)	Guidance on minimum elements of a cryptographic bill of materials. The FAR Council proposes adding cryptographic vulnerabilities to contractor disclosure programs.	CISA, NIST, FAR Council
Dec 31, 2027	NIST pilot migration complete	NIST
Dec 31, 2030	PQC key establishment on high value and high-impact systems. Covered contractors comply with PQC-inclusive FIPS.	Agencies, contractors
Dec 31, 2031	PQC digital signatures on high value and high-impact systems	Agencies

Sources: Federal Register, EO 14412; NSA CNSA 2.0 FAQ.

“High-impact” means systems rated high under FIPS 199. “High value assets” are the systems designated under OMB M-19-03. These are the systems whose compromise would hurt the most.

Two deadlines, two different problems

Executive Order 14412 splits the migration in two for a reason. Key establishment (the handshake that protects data in transit) comes first because it is the target of harvest-now-decrypt-later attacks. Much of that work can happen at the network layer, often without touching applications. Digital signatures come a year later because they run through certificate authorities, code-signing pipelines, firmware and identity systems. Post-quantum signatures are also larger, and that affects handshake performance. If certificates already strain your team, read our guide to certificate lifecycle management in 2026 before you plan the signature phase.

Who Executive Order 14412 Really Reaches

The order is written for federal agencies, but its effects spread outward through contracts, supply chains and regulators.

Federal contractors and the FAR flow-down

Contractors already handle federal information under clauses such as FAR 52.204-21. Executive Order 14412 directs the FAR Council to propose a rule requiring covered contractors to comply with NIST’s FIPS standards, including the PQC algorithms, by December 31, 2030. A second proposed rule would require contractor vulnerability disclosure programs to cover cryptographic weaknesses, including “the use of non-FIPS approved algorithms.” Neither rule has been proposed yet. Expect flow-down clauses to pass these obligations from prime contractors to subcontractors and managed service providers.

The defense industrial base

One day after the order, the Department of War released its Post-Quantum Cryptography Strategy. The strategy says every system must support PQC by the end of 2030 or be phased out, and must use PQC by the end of 2031. It also commits to moving the defense industrial base to PQC through the CMMC program, whose own rollout schedule is still changing. For National Security Systems, NSA’s CNSA 2.0 advisory keeps its own timeline.

Cloud, SaaS and technology vendors

Providers authorized through FedRAMP should expect PQC questions in authorization packages. CISA has already published a list of product categories that use PQC standards (January 2026). The list signals where federal buyers will look first: cloud services, web software, endpoint security and networking. If you sell technology, PQC support is quickly becoming a requirement to be considered at all.

Financial services, healthcare and insurance

These sectors are not named in Executive Order 14412, but they sit close to it. Public companies already report material cyber incidents under the SEC’s 2023 disclosure rules. New York’s NYDFS Part 500 now requires asset inventories. Banks follow FFIEC cybersecurity guidance, and healthcare organizations protect patient data under the HIPAA Security Rule. All of these frameworks draw on NIST. In our experience, once the federal government sets a date, examiners, auditors and cyber insurers start using it as the benchmark for “reasonable” security. For AI-driven risk in the same sectors, see our analysis of blind agent transfer in financial services.

The Inventory Problem Executive Order 14412 Exposes

You cannot migrate cryptography you cannot find. Federal agencies have had inventory duties since 2023, and CISA published a strategy for automated PQC discovery and inventory tools to help. The NIST National Cybersecurity Center of Excellence runs a Migration to Post-Quantum Cryptography project focused on the same problem. Even so, most private organizations still cannot produce a complete cryptographic inventory when asked.

That is why the order’s CBOM milestone matters. A cryptographic bill of materials lists the algorithms, key lengths, libraries, certificates and protocols inside a product or system. Once CISA and NIST define its minimum elements, expect CBOMs to show up in procurement questionnaires next to software bills of materials.

Where quantum-vulnerable cryptography hides

WAN and VPN tunnels: IPsec and TLS overlays in SD-WAN deployments and site-to-site links. See how quantum computing affects security protocols.
Carrier transport: traffic that is assumed to be private but is often unencrypted. Ask whether your MPLS traffic is safe.
Edge devices: firewalls, load balancers and TLS terminators. These are the attack surface we covered in network edge security in 2026.
Stored data: backups, archives and databases encrypted with keys protected by RSA or ECC.
Identity and signing: PKI, code signing, firmware updates, SSO tokens and machine identities.
Third parties: SaaS APIs, payment processors and managed service providers whose cryptography you do not control.

Crypto-Agility: The Capability Executive Order 14412 Quietly Demands

The PQC algorithms will keep changing. HQC is still being standardized, and implementation guidance keeps evolving. NIST’s CSWP 39 on crypto-agility, updated in June 2026, describes how to design systems so algorithms can be replaced without rebuilding them. NIST SP 800-227 gives recommendations for using key-encapsulation mechanisms such as ML-KEM.

Validation matters too. Executive Order 14412 directs NIST to speed up the Cryptographic Module Validation Program, and federal buyers will increasingly ask for modules validated under FIPS 140-3. Adoption is already underway: Cloudflare reports that more than two-thirds of browser traffic to its network uses post-quantum encryption. The network layer is where many enterprises can move fastest, because a quantum-safe transport protects every application that runs over it. That idea is the basis of our post-quantum cryptography migration playbook.

A 270-Day Executive Order 14412 Readiness Plan

This plan follows the order’s own 30/90/180/270-day structure, adapted for private-sector organizations. It fits contractors, regulated enterprises and any company that holds long-lived sensitive data.

Days 0–30: Assign ownership

Name a PQC migration lead who reports to the CIO or CISO, as the order requires of agencies.
Brief the board on Executive Order 14412, the 2030 and 2031 dates, and your harvest-now-decrypt-later exposure.
List the data that must stay confidential beyond 2030: patient records, financial records, intellectual property and legal files.

Days 31–90: Build a quantum impact inventory

Run automated discovery across networks, endpoints and cloud. Rank systems by impact rather than waiting for a perfect audit.
Send vendors a PQC questionnaire covering their algorithm roadmap, FIPS 140-3 validation status and whether they can supply a CBOM.
Map your cryptography to the CISA PQC initiative categories so reports use a consistent vocabulary.

Days 91–180: Protect data in motion first

Put quantum-resistant protection on your highest-risk WAN links, data center interconnects and cloud on-ramps.
Pilot hybrid (classical plus PQC) key exchange and measure latency and compatibility.
Track the FAR Council’s proposed rule and comment on it if you are a federal supplier.

Days 181–270: Prepare for CBOMs, disclosure and signatures

Get your inventory into a form that can meet the coming CBOM requirements.
Update your vulnerability disclosure policy to accept reports of cryptographic weaknesses.
Draft the PKI and code-signing roadmap for the 2031 signature deadline, and budget for 2027–2031.

How ibm/SEIMless Helps You Meet Executive Order 14412

ibm/SEIMless combines more than 20 years of vendor-agnostic carrier, cloud and communications experience with its role as OEM of Exodus QRN quantum-resistant networking. That combination lets us work at the layer where Executive Order 14412 can be met fastest.

Exodus QRN Data in Motion protects traffic across WAN, cloud and data center links against harvest-now-decrypt-later collection.
Exodus QRN Data at Rest and Exodus Transparent Encryption protect stored data without rewriting applications.
Exodus Key Management centralizes the key lifecycle so you can change algorithms quickly.
QR Edge, the Exodus NxtGen Firewall and Zero Trust Content Security harden the edge. For background, read what zero trust means.
MPLS replacement solutions and cloud services modernize transport while you migrate.

We encourage every buyer to ask each vendor, ibm/SEIMless included, for its exact algorithm list, validation status and CBOM plan. We are glad to walk you through ours. To see how the pieces fit, explore Exodus QRN infrastructure for the post-quantum era and why quantum-resistant networking is becoming a business necessity.

Frequently Asked Questions About Executive Order 14412

What is Executive Order 14412?

Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” was signed June 22, 2026. It requires federal agencies to move high value assets and high-impact systems to NIST-approved post-quantum cryptography, and it starts rulemaking that will extend PQC requirements to federal contractors.

When do the Executive Order 14412 deadlines take effect?

Agencies had 30 days to name migration leads. OMB guidance is due at 90 days (on or about September 20, 2026). The contractor rule is due to be proposed at 180 days, and CBOM guidance at 270 days. PQC key establishment is required by December 31, 2030 and PQC digital signatures by December 31, 2031.

Does Executive Order 14412 apply to private companies?

Not directly, with one major exception. Federal contractors will be covered once the FAR Council finalizes its rule, which proposes compliance by December 31, 2030. Other private organizations will feel the order through supply-chain flow-downs, customer requirements and regulators that rely on NIST standards.

What is a cryptographic bill of materials (CBOM)?

A CBOM is a machine-readable inventory of the cryptographic algorithms, keys, certificates, libraries and protocols in a product or system. Executive Order 14412 directs CISA and NIST to define its minimum elements so cryptographic risk can be assessed automatically.

How is Executive Order 14412 different from NSM-10 and OMB M-23-02?

NSM-10 set a 2035 goal, and M-23-02 required annual inventories. Executive Order 14412 adds binding 2030 and 2031 dates for the most sensitive federal systems, a named migration lead in every agency, procurement rules for contractors and CBOM guidance.

What should my organization do first?

Assign an executive owner, identify data that must stay confidential beyond 2030, and protect data in transit on your highest-risk links. Network-layer quantum-resistant protection can deliver results in months while application and PKI work continues.

Don’t Wait for the FAR Rule. Start Your Quantum-Safe Transition Today.

Executive Order 14412 sets the dates, but the people who depend on your organization need protection now. ibm/SEIMless and Exodus QRN can help you inventory your cryptography, protect data in motion and build a practical migration plan for your board.

Contact Us

Call: 646-546-5245
Email: in**@**********ss.com
Visit: One Liberty Plaza, New York, NY 10006

More resources: About ibm/SEIMless · FAQs · Blog · Agentic AI security meets Q-Day

The Hidden Risk of AI-to-AI “Blind Agent Transfer” in Financial Services

by hannahadmin | Sep 14, 2026 | Agentic AI, Next-gen Security solutions, Seimless

Every bank, insurer, and broker-dealer in America now runs software that hands work to other software without a human in the loop. The failure mode nobody has named yet is blind agent transfer: the moment one AI agent passes a task, a context window, and an inherited set of permissions to a second agent that cannot verify who originally asked, what they were actually authorized to do, or whether the instruction was ever legitimate. A blind agent transfer is not a bug in any single model. It is a gap in the architecture between them — and in financial services, that gap sits directly on top of money movement, customer identity, and regulatory recordkeeping.

The industry spent three years hardening the prompt. It spent almost no time hardening the handoff. That is the wrong order, and the standards bodies have started saying so out loud.

DEFINITION

Blind agent transfer is an automated handoff between two or more AI agents in which the receiving agent acts on inherited instructions, context, and credentials without independently verifying the identity of the original requester, the scope of delegated authority, or the provenance of the context it was given. The result is an action that executes with real-world consequence but no unbroken chain of accountability back to a human principal.

What a Blind Agent Transfer Actually Looks Like Inside a Bank

Abstract risk does not move budgets, so here is the concrete version. A mid-size commercial bank deploys a servicing assistant that handles inbound payment-exception requests. It is read-only by design. When it encounters an exception it cannot resolve, it calls an operations agent that holds write access to the payments queue. That operations agent, in turn, calls a treasury tooling agent through a Model Context Protocol server to check available balance and release the item.

Three agents. Two handoffs. One service account.

The servicing assistant did its job. The operations agent received a well-formed task with a plausible customer reference and a summary of the conversation. It did not receive — because nothing in the architecture required it — a cryptographically verifiable assertion of which authenticated customer started the thread, what entitlements that customer holds, or whether the summarizing agent was itself manipulated. That is a textbook blind agent transfer. If the original inbound message contained an indirect prompt injection buried in an attached remittance advice, the injection does not have to defeat the agent with write access. It only has to survive one summarization step and ride the handoff.

This is the same structural weakness that made third-party compromise the dominant breach vector of the last two years — the pattern we broke down in our analysis of escalating third-party cyber risk after the Ericsson service-provider hack and in our post-mortem of the Change Healthcare breach. Trust that is inherited rather than proven is the vulnerability. Agentic architectures simply industrialize it.

Why Financial Services Is the Worst Possible Place for Blind Agent Transfer

Other sectors can absorb an unattributable automated action. Regulated finance cannot, because four separate obligations all assume a traceable human principal.

Model risk governance. The Federal Reserve issued SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026, superseding the fifteen-year-old SR 11-7 framework that most institutions still built their inventories around. Multi-agent chains complicate the most basic question those frameworks ask: what is the model, where does it end, and who owns its output? A blind agent transfer makes the boundary unanswerable.

Third-party and vendor risk. Under the Interagency Guidance on Third-Party Relationships (OCC Bulletin 2023-17, also published in the Federal Register), a banking organization remains responsible for activities performed by third parties. When an internal agent silently delegates to a vendor-hosted agent, that delegation is a third-party relationship that no one filed.

Supervisory conduct rules. FINRA reminded members in Regulatory Notice 24-09 that existing supervisory obligations apply in full to generative AI and large language models, and its 2026 Annual Regulatory Oversight Report continues to press on emerging Gen AI trends. FINRA’s broader artificial intelligence topic page is the current reference point for member firms.

Cybersecurity program requirements. New York’s Department of Financial Services published an industry letter on cybersecurity risks arising from artificial intelligence that explicitly ties AI risk back to the access-control and third-party provisions of Part 500. Meanwhile, the SEC’s cybersecurity disclosure rules put a four-business-day clock on material incidents — a clock that starts whether or not your logs can explain which agent did what.

Layer on Treasury’s report on AI in financial services, FinCEN’s alert on deepfake and generative-AI fraud schemes (FIN-2024-Alert004), and the examination expectations codified across the FFIEC IT Examination Handbook, and the compliance picture is unambiguous. Autonomy without attribution is a finding waiting to be written.

The Four Failure Modes of Blind Agent Transfer

1. Identity collapse

Most production agent stacks authenticate the platform, not the principal. Every downstream call arrives wearing the same service identity, so the receiving agent sees a trusted caller and nothing more. NIST opened a formal workstream on precisely this problem with its February 5, 2026 concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. The paper’s framing is telling: the risk comes from giving agents access to diverse data, tools, and applications without adequate identification and authorization safeguards.

2. Authority inflation

This is the classic confused-deputy problem wearing new clothes. A low-privilege agent induces a high-privilege agent to act on its behalf, and the privileged agent obliges because the request is well-formed. Nothing is technically broken. The permissions worked exactly as written. They were simply written for a world with one actor per token. Token-exchange standards such as IETF RFC 8693 and the OAuth security best practices in RFC 9700 exist to carry delegation semantics properly — and are routinely skipped in agent deployments.

3. Context laundering

Every summarization step strips provenance. Text that entered the system as untrusted customer input leaves the first agent as an authoritative-sounding internal task description. By the third hop, no marker distinguishes attacker-supplied content from verified record data. The OWASP Top 10 for Agentic Applications (2026), released December 9, 2025, catalogs this family of risks, as does MITRE ATLAS and NIST’s adversarial machine learning taxonomy, NIST AI 100-2 E2025.

4. The audit gap

Ask most institutions to reconstruct a four-agent decision chain from ninety days ago and you will get application logs, not an evidentiary record. There is no signed assertion at each hop, no immutable ordering, and frequently no retention of the intermediate context at all. That is the difference between telemetry and an audit trail, and examiners know it.

What the Standards Bodies Are Now Saying About Agent Handoffs

The single most useful document published on this topic came from an unexpected source. On May 20, 2026, the National Security Agency’s Artificial Intelligence Security Center released Model Context Protocol: Security Design Considerations for AI-Driven Automation. Its language maps almost word-for-word onto blind agent transfer: agentic systems introduce “novel and systemic risks like dynamic tool invocation, implicit trust relationships, and context sharing,” and “misaligned assumptions or subtle inconsistencies at any stage can propagate and compound into exploitable conditions.” NSA’s conclusion is that the agentic environment must be treated as a continuum rather than a set of independently patchable endpoints.

NIST is building the control layer underneath that conclusion. The Control Overlays for Securing AI Systems (COSAiS) project, announced in the CSRC’s control overlays initiative, is producing five overlays on top of SP 800-53 Rev. 5 — and two of the five are specifically for AI agent systems, split between single-agent and multi-agent use cases. The existence of a dedicated multi-agent overlay is the clearest institutional signal available that agent-to-agent trust is now treated as its own control domain.

Alongside it sit the tools most institutions already have on the shelf: the NIST AI Risk Management Framework, SP 800-207 Zero Trust Architecture, the identity assurance model in SP 800-63-4, reference builds from the National Cybersecurity Center of Excellence, CISA’s artificial intelligence program and joint guidance on deploying AI systems securely, the CISA Zero Trust Maturity Model, Secure by Design commitments, and the KEV catalog for the underlying infrastructure those agents run on. GAO’s AI oversight work and the CFPB’s research on chatbots in consumer finance round out the U.S. policy picture.

Blind Agent Transfer Is a Network Problem Before It Is a Model Problem

Here is the uncomfortable conclusion most AI security vendors avoid: you cannot fix blind agent transfer inside the model layer. Guardrails, evaluations, and system prompts all operate on content. The failure is about identity, authority, and provenance in transit — which is network and cryptographic territory.

That is precisely where ibm/SEIMless built Exodus Quantum Resistant Networking. When agent-to-agent traffic crosses a segmented, cryptographically authenticated fabric rather than a flat internal network, the handoff becomes something you can actually govern:

Data-in-motion protection and Exodus PIET put verifiable, quantum-resistant encryption around every inter-agent session instead of trusting a shared internal VLAN.
Exodus Key Management issues and rotates distinct cryptographic identities per workload, which is the practical antidote to identity collapse.
Zero-trust content security and the Exodus NxtGen Firewall enforce policy at each hop, so a privileged agent is not reachable simply because a lower-tier agent already sits inside the perimeter.
QR Edge extends that enforcement to branch, ATM, and remote-operations footprints where exception handling actually happens.
Exodus ARIA ADR and endpoint detection and response give you the behavioral record that turns an agent chain into evidence.
Data-at-rest protection and transparent encryption cover the stored context windows and transcripts that agent chains leave behind.

For institutions still running exception workflows over legacy transport, our comparisons of MPLS security assumptions, SD-WAN architecture, and why today’s software-defined networks are not future-ready are the right starting point. Our Nxt-Gen Network Security Solutions overview maps the full control set.

A Seven-Control Blueprint to Eliminate Blind Agent Transfer

Control	What it stops
1. Per-agent cryptographic identity — no shared service accounts across hops	Identity collapse
2. Signed delegation chains — carry the original principal and scope through every transfer using proper token exchange	Authority inflation
3. Provenance tagging — mark untrusted input at ingest and preserve the tag through summarization	Context laundering
4. Privilege ceilings — a receiving agent may never exceed the effective entitlements of the originating human	Confused deputy escalation
5. Human checkpoints on money movement — irreversible actions require re-authentication, not inherited authority	Unattributable transactions
6. Immutable handoff logging — signed, ordered, retained records of every transfer	The audit gap
7. Network segmentation between agent tiers — reachability follows policy, not topology	Lateral agent abuse

Control five is the one institutions argue about, because it trades away some of the automation ROI. It is also the one that will look obvious in hindsight. No examiner has ever accepted “the agent decided” as a control narrative.

The Quantum Overlay Nobody Is Modeling Yet

There is a second-order consequence of blind agent transfer that almost no risk register has caught. Multi-agent systems generate an enormous volume of intermediate context — customer PII, account detail, internal reasoning about credit and fraud decisions — and that context traverses the network and lands in storage. Under a harvest-now, decrypt-later posture, an adversary does not need to break the agent chain today. They only need to capture it.

NIST has already set the deprecation schedule for classical public-key cryptography in NIST IR 8547, and vulnerabilities in the surrounding stack keep arriving through the National Vulnerability Database. We covered the economics of that exposure in harvest now, decrypt later, the sequencing in our post-quantum cryptography migration playbook, and the collision of both timelines in agentic AI security meets Q-Day. Agent chatter is the richest harvest target most institutions have ever created, and it is usually the least protected.

Questions Your Board Will Ask Before the Next Audit Cycle

How many agent-to-agent handoffs occur in production today, and which of them touch money movement or customer identity?
For any given automated action last quarter, can we produce a signed chain back to an authenticated human principal?
Which agents can invoke third-party or vendor-hosted agents, and are those relationships in our third-party inventory?
What is our maximum blast radius if the highest-privilege agent acts on a laundered instruction?
Are agent transcripts and intermediate context encrypted with quantum-resistant protection in motion and at rest?

If the answer to the second question is “not reliably,” blind agent transfer is already in the environment. It simply has not been named in a finding yet. Related reading: what zero trust actually means, our shadow AI enterprise playbook, the rise of AI agents, AI’s arrival on Wall Street, AI governance under pressure, AI-native networks, and why quantum-resistant networking is now a business necessity.

Blind Agent Transfer: Frequently Asked Questions

What is blind agent transfer in simple terms?

Blind agent transfer is when one AI agent hands a task to another AI agent along with inherited context and permissions, and the receiving agent acts without verifying who originally made the request or whether that person was authorized. The action executes, but the accountability chain back to a human is broken.

How is blind agent transfer different from prompt injection?

Prompt injection is the attack; blind agent transfer is the condition that lets the attack travel. An injection only has to compromise the first, least-privileged agent. If handoffs carry no verified identity or provenance, the malicious instruction is laundered into a trusted-looking internal task and delivered to an agent that can actually act.

Why is this specifically dangerous in banking and insurance?

Because model risk, third-party risk, supervisory, and incident-disclosure obligations all assume a traceable principal behind every action. Guidance including Federal Reserve SR 26-2, OCC Bulletin 2023-17, FINRA Regulatory Notice 24-09, and the NYDFS AI industry letter presumes you can answer who authorized what. A blind agent transfer makes that unanswerable.

Can guardrails or AI firewalls prevent blind agent transfer?

Only partially. Content filters inspect what agents say. Blind agent transfer is a failure of identity, delegated authority, and provenance in transit, which lives in the network and cryptographic layer. Per-workload identity, signed delegation, segmentation, and immutable handoff logging are the controls that close it.

Does the Model Context Protocol make this worse?

MCP makes tool invocation dramatically easier, which expands the number of handoffs without necessarily improving verification. NSA’s May 2026 security design considerations for MCP flag dynamic tool invocation, implicit trust relationships, and context sharing as systemic risks, and advise treating the agentic environment as a continuum rather than isolated endpoints.

Where should a financial institution start?

Inventory every agent-to-agent handoff that touches money movement or customer identity, then apply per-agent cryptographic identity, signed delegation, privilege ceilings, and human re-authentication on irreversible actions. ibm/SEIMless can assess the network layer beneath those agents and deploy quantum-resistant segmentation through Exodus QRN.

Blind agent transfer is solvable — but not at the model layer. ibm/SEIMless Communications Technologies, Inc., home of Exodus QRN, Inc., has spent more than 20 years securing the networks that regulated institutions run on, and we build quantum-resistant infrastructure for the agentic era. Let our team assess where your agent chains cross unprotected ground.

Contact Us | Our Blog | Our Services | See Previous Post…

Certificate Lifecycle Management in 2026: The FIPS 140-2 Sunset, Shrinking TLS Lifetimes, and the Crypto-Agility Deadline Nobody Budgeted For

by hannahadmin | Sep 8, 2026 | blog, QRN, Seimless

Crypto-Agility & Compliance

Three separate clocks are converging on the same overloaded team. Here is what changes on September 21, what changes again in March, and how to automate your way out before an expired certificate takes down a payment rail.

ibm/SEIMless Communications Technologies, Inc.

For most enterprises, certificate lifecycle management has never been a strategic conversation. It was a spreadsheet, a shared mailbox, and a calendar reminder that someone set three years ago and nobody has looked at since. That arrangement is about to fail — not gradually, but on specific, published dates that are already on the federal record.

13 DAYS REMAINING

September 21, 2026. Every FIPS 140-2 validated cryptographic module moves to the NIST Historical List. From that point forward, those modules are supported for existing systems only — not for new federal procurements, and not for the compliance attestations your customers are about to start asking for.

At the same time, the maximum lifetime of a public TLS certificate has already dropped to 200 days, on its way to 100 days in March 2027 and 47 days in March 2029. And NIST has formally scheduled the retirement of the RSA and elliptic-curve cryptography that virtually every certificate in your estate depends on today.

Individually, each of these is a project. Together, they are a structural change in how networks have to be built. This post explains all three, shows which one hits your industry first, and lays out the certificate lifecycle management playbook we use at ibm/SEIMless to get enterprises from manual renewal to genuine crypto-agility.

What Is Certificate Lifecycle Management?

DEFINITION

Certificate lifecycle management (CLM) is the discovery, issuance, deployment, monitoring, renewal, rotation, and revocation of every digital certificate and cryptographic key across an organization’s network — servers, load balancers, VPN concentrators, firewalls, APIs, containers, IoT endpoints, and machine-to-machine identities. Mature certificate lifecycle management is automated, inventoried, and algorithm-agnostic, so that a cryptographic standard can be swapped out without re-architecting the network.

The critical word in that definition is algorithm-agnostic. Historically, certificate lifecycle management was about not letting things expire. In 2026, it is about being able to change what your certificates are made of — quickly, at scale, and more than once. NIST’s National Cybersecurity Center of Excellence calls this property crypto-agility, and it now drives every serious network design conversation we have.

Deadline One: FIPS 140-2 Validation Sunsets This Month

The Cryptographic Module Validation Program, jointly run by NIST and Canada’s cyber centre, is the arbiter of whether a cryptographic module can be used in U.S. federal systems. Its transition schedule has been public for years, and it lands this month.

April 1, 2022: CMVP stopped accepting new FIPS 140-2 validation submissions. Everything issued since has been FIPS 140-3.
September 21–22, 2026: All remaining FIPS 140-2 certificates move to the Historical List. Per the CMVP program page, agencies may continue using those modules for existing systems only. The FIPS 140-3 Transition Effort page documents the same milestone.
After that date: New procurements, FedRAMP packages, CMMC assessments, and downstream vendor questionnaires increasingly require FIPS 140-3 validated modules.

Here is the part that catches people out: this is not only a government problem. FIPS validation is written into commercial contracts across banking, insurance, and healthcare because it is the cheapest available shorthand for “this crypto was independently tested.” When your module drops to the Historical List, your customer’s procurement team sees it in their next vendor review — and the burden of proof lands on you.

The practical question is not “are we compliant today.” It is: can you produce, on request, a list of every module in your environment and its current validation status? Most organizations cannot, which is precisely the certificate lifecycle management gap. Federal agencies have been under an explicit cryptographic inventory mandate since the White House issued OMB Memorandum M-23-02; the private sector is simply arriving at the same requirement through contracts instead of memos. If your organization sells into the defense supply chain, the same evidence is expected under CMMC and, for cloud services, under FedRAMP.

Deadline Two: TLS Certificate Lifetimes Are Collapsing Toward 47 Days

In April 2025, the CA/Browser Forum passed Ballot SC-081v3, which sets a staged reduction in the maximum validity of publicly trusted TLS certificates. The schedule is not a proposal. It is in force.

Effective period	Max certificate validity	Max domain validation reuse	Renewals per year
Through March 14, 2026	398 days	398 days	~1
March 15, 2026 – March 14, 2027	200 days (current)	200 days	~2
March 15, 2027 – March 14, 2029	100 days	100 days	~4
March 15, 2029 onward	47 days	10 days	~8

Read the right-hand column again. An enterprise that renews 400 public certificates once a year today will be executing roughly 3,200 renewal events per year by 2029 — plus domain revalidation every ten days. No staffing model absorbs that. This is the single clearest argument for automated certificate lifecycle management ever put in front of a CFO, because the labor math stops working long before the security math does.

It also changes the blast radius of a mistake. When certificates lasted over a year, a missed renewal was an embarrassment. When they last 47 days, a broken automation pipeline silently expires your entire estate inside two months. NIST’s TLS Server Certificate Management project (SP 1800-16) documents exactly this failure pattern, and NIST SP 800-52 Rev. 2 remains the federal baseline for TLS configuration itself.

Deadline Three: NIST Has Scheduled the Retirement of RSA and ECC

The third clock is the one this company was built around. In NIST IR 8547, NIST published a transition timeline for the classical algorithms underpinning today’s certificates:

After 2030: RSA, ECDSA, ECDH, and finite-field Diffie-Hellman at 112-bit security strength are deprecated
After 2035: those algorithms — including their 128-bit-and-above variants — are disallowed

Replacements are already standardized: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures, finalized by NIST in August 2024. The NSA’s Commercial National Security Algorithm Suite 2.0 sets an even more aggressive posture for national security systems — see the CNSA 2.0 FAQ and the broader NSA cybersecurity guidance library.

Post-quantum certificates are also structurally different: ML-DSA signatures and public keys are substantially larger than their ECC equivalents. That changes handshake sizes, MTU behavior, load balancer buffers, and embedded device storage. You do not discover those problems in a policy document — you discover them the first time you try to deploy a real certificate through your real network. Which is why the inventory has to come first, and why we cover the underlying mathematics in our explainer on quantum computing and encryption.

Why Certificate Lifecycle Management Is Really a Quantum-Resistance Problem

Treat these as three unrelated compliance chores and you will run three unrelated projects, three times, over the next decade. Treat them as one problem and the answer is singular: build a network that can change its cryptography on demand.

That is the whole thesis of crypto-agility, and every U.S. authority now converges on it. CISA’s Post-Quantum Cryptography Initiative makes cryptographic discovery and inventory the first step in its migration model; its Strategy for Migrating to Automated PQC Discovery and Inventory Tools is explicit that manual inventories do not scale. The NIST Cybersecurity Framework 2.0 puts asset identification ahead of protection for the same reason. Automated certificate lifecycle management is how that identification stays true from one week to the next.

And the urgency is not theoretical. Adversaries are already capturing encrypted traffic today to decrypt once a cryptographically relevant quantum computer exists — the pattern we covered in Harvest Now, Decrypt Later. Data with a ten-year confidentiality requirement is already exposed. Certificates are simply the control plane you use to fix it.

What Breaks First, by Industry

Financial Services and Insurance

Payment rails, trading systems, and claims platforms carry the highest density of machine identities and the lowest tolerance for downtime. Examiners are already asking. The FFIEC IT Examination Handbook covers encryption and key management directly; New York institutions face NYDFS Part 500, which mandates encryption controls and annual review; and public companies must disclose material incidents under the SEC’s cybersecurity disclosure rules. An outage caused by an expired certificate is an operational event you will be explaining in writing.

Healthcare

Medical records carry decades-long confidentiality obligations, which makes healthcare the most exposed vertical to harvest-now-decrypt-later. The HIPAA Security Rule requires encryption of ePHI in transit and at rest, and clinical environments are dense with long-lived embedded devices that were never designed for 47-day certificate rotation. Those devices are where certificate lifecycle management programs quietly fail.

Carriers, MSPs, and Multi-Nationals

Providers inherit their customers’ obligations. If you operate infrastructure on behalf of regulated clients, every one of these three deadlines arrives as a contractual question from a client procurement team — often all three in the same questionnaire. Consumer-facing firms should also review the FTC Safeguards Rule, which sets encryption expectations for non-bank financial institutions.

The ibm/SEIMless Certificate Lifecycle Management Playbook

This is the sequence we run with clients. It is deliberately ordered — each step makes the next one cheaper.

1. Build a cryptographic bill of materials

Discover every certificate, key, algorithm, key length, module, and expiry across data centers, cloud, branch, and remote endpoints. Include internal PKI, not just public certificates — internal estates are typically three to ten times larger and far less governed. Correlate findings against the National Vulnerability Database and the CISA Known Exploited Vulnerabilities Catalog so cryptographic debt and exploitable debt are ranked on one list.

2. Automate issuance and renewal — with no exceptions

Any certificate that a human renews by hand is a certificate that will expire. At 200 days it is a risk; at 47 days it is a certainty. ACME-based automation should be the default path, and every exception should carry a named owner and a documented reason.

3. Re-validate every module against FIPS 140-3

Map each cryptographic module to its validation certificate and its status after this month’s Historical List transition. Where a vendor has no FIPS 140-3 path, that is a procurement decision, not an engineering one — escalate it now, while you still have runway.

4. Test hybrid and post-quantum certificates in a real lab

Deploy ML-KEM hybrid key exchange and ML-DSA certificates against representative load balancers, firewalls, and clients. Measure handshake size, latency, and failure modes. Our data in motion and data at rest practices exist for exactly this validation work.

5. Centralize key custody

Certificate lifecycle management fails when keys live in a dozen places under a dozen policies. Consolidate custody, rotation, and escrow under a single governed service — the role our Exodus key management platform plays.

6. Rehearse the emergency rotation

Assume a certificate authority is compromised, or an algorithm is broken, on a Friday afternoon. How many hours to rotate everything? If the answer is unknown, it is too long. Run the drill, measure it, shorten it, repeat annually.

7. Write crypto-agility into contracts

Every renewal from here forward should require FIPS 140-3 validation, a published post-quantum roadmap, and automated certificate lifecycle management support. Buying it into the estate is cheaper than retrofitting it.

How Exodus QRN Makes This Operational

ibm/SEIMless has spent more than twenty years as a vendor-agnostic integrator, which is how we saw the flaw in SD-WAN and SASE early enough to build past it. Exodus QRN was designed on the assumption that cryptographic standards will keep changing — so certificate and algorithm changes are configuration, not reconstruction.

Quantum-resistant networking built on NIST-standardized post-quantum algorithms with hybrid transition modes
Transparent encryption that protects traffic without rewriting applications
NxTGen firewall and zero trust content security so certificate identity and access policy are enforced together
Exodus Aria ADR and endpoint detection and response for the machine identities the network cannot see on its own
SD-WAN and managed network services that carry quantum-safe policy consistently to every branch and remote site

Because we manufacture as an OEM and remain carrier- and cloud-agnostic, we can rebuild the cryptographic layer without forcing a wholesale hardware refresh — the difference between a migration and a rip-and-replace. Our earlier post-quantum cryptography migration playbook covers the algorithm-selection layer that sits beneath this certificate work.

Frequently Asked Questions

What is certificate lifecycle management in simple terms?

It is the end-to-end process of finding, issuing, deploying, renewing, rotating, and revoking every digital certificate and key in an organization. Modern certificate lifecycle management is automated and algorithm-agnostic so cryptography can be replaced without redesigning the network.

What happens to FIPS 140-2 certificates on September 21, 2026?

They move to the CMVP Historical List. Per NIST, agencies may continue using those modules for existing systems only. New procurements and most compliance attestations will expect FIPS 140-3 validated modules.

Are TLS certificates really dropping to 47 days?

Yes, on a staged schedule set by CA/Browser Forum Ballot SC-081v3: 200 days as of March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029, with domain validation reuse falling to 10 days.

When do RSA and ECC actually stop being allowed?

NIST IR 8547 deprecates 112-bit RSA and elliptic-curve algorithms after 2030 and disallows RSA, ECDSA, ECDH, and Diffie-Hellman after 2035. Systems holding data with long confidentiality lifetimes should migrate well ahead of those dates.

Can we handle 47-day certificates without automation?

Realistically, no. A 400-certificate estate moves from roughly 400 renewal events per year to roughly 3,200, plus domain revalidation every ten days. Automated certificate lifecycle management is the only model that scales.

Should we wait for post-quantum standards to settle before starting?

No. The three primary standards — FIPS 203, 204, and 205 — were finalized in August 2024. Inventory and automation work is valuable regardless of which algorithms you eventually deploy, and it is the long pole in every migration we have run.

The Bottom Line

Certificate lifecycle management stopped being a maintenance task the moment the renewal cadence outgrew the people doing it. Between the FIPS 140-2 sunset this month, TLS validity shrinking toward 47 days, and NIST’s deprecation of RSA and ECC, the enterprises that automate now will absorb every one of these changes as a configuration update. The ones that wait will absorb them as outages, failed audits, and emergency projects priced at three times the cost.

The work is knowable and the deadlines are published. What separates the two outcomes is whether you start before or after something breaks.

Talk to ibm/SEIMless Today

Our engineers will run a cryptographic discovery across your environment, map every certificate and module against the September 2026 FIPS transition and the SC-081v3 validity schedule, and deliver a prioritized certificate lifecycle management roadmap built on Exodus QRN. No obligation, no pressure from salespeople selling far less capable systems.

Call 646-546-5245 Email in**@**********ss.com

Headquarters One Liberty Plaza, New York, NY 10006

Start here Get Started · Contact Us · Services · FAQs · About Us

Network Edge Security in 2026: Why Attackers Now Come Through Your Firewall, Not Your Inbox

by hannahadmin | Sep 4, 2026 | cybersecurity, Next-gen Security solutions, Seimless, WAN

Network edge security has quietly become the single highest-leverage control in the enterprise, and the 2026 incident data explains why. Exploits are now the leading way attackers get in, for the sixth year running. Email phishing has fallen to a fraction of what it was. The front door moved, and most security budgets have not followed it.

That shift is uncomfortable, because network edge security is exactly where traditional tooling goes blind. Your endpoint agent does not run on a VPN concentrator. Your SIEM may not receive its logs. Meanwhile the device sits on the public internet, holds credentials for the network behind it, and often runs firmware nobody has touched in three years.

At ibm/SEIMless, we have spent more than two decades designing and operating enterprise networks. This guide sets out what changed in 2026, what the numbers actually show, how a modern edge compromise unfolds, and a practical program to close the gap.

What Network Edge Security Means in 2026

The edge is no longer a single boundary device. It is every internet-facing appliance that terminates a session, holds a credential, or routes traffic between trust zones.

That list is longer than most inventories admit. It includes firewalls, VPN gateways, SD-WAN appliances, load balancers, secure web gateways, remote access servers, routers, branch switches, out-of-band management interfaces, and file transfer appliances. Furthermore, it includes every one of those devices at every branch, not only at headquarters.

The Edge Grew While Nobody Redrew the Map

Three changes expanded the edge without anyone deciding to expand it, and each one widened the network edge security problem.

Remote work multiplied VPN and gateway capacity, and much of that emergency capacity is still running. Branch networks moved from private circuits to internet underlays, which put appliances at every site on the public internet. Cloud adoption added a second edge in front of workloads that used to sit safely inside a data center.

Consequently, the attack surface grew faster than the asset inventory. Ask most teams for a complete list of internet-facing appliances by firmware version and you will get a spreadsheet that is at least a quarter out of date. That inventory gap is the real vulnerability, and everything else follows from it. Our guidance on enterprise IT infrastructure services starts from exactly this point.

The 2026 Data: Exploits Beat Phishing, and the Edge Is Where They Land

Three major datasets published this year point the same direction on network edge security, which is unusual and worth taking seriously.

Exploits Are Now the Number One Way In

Mandiant’s M-Trends 2026, released on 23 March 2026, found exploits responsible for 32% of initial infections, the most common vector for the sixth consecutive year. Voice phishing came second at 11%, and prior compromise third at 10%.

Email phishing, by contrast, accounted for just 6% of cases, down from 22% in 2022. Automated email controls worked. Therefore attackers moved to the surface those controls do not cover.

Verizon’s 2026 Data Breach Investigations Report reaches a similar conclusion from a different dataset, reporting that 31% of breaches now start with software vulnerabilities, overtaking stolen passwords as the leading entry point.

Twenty-Two Seconds From Access to Handoff

The most alarming number in M-Trends is not about entry at all. It is about speed.

In 2022, the median gap between an initial access event and handoff to a secondary threat group ran to more than eight hours. In 2025, that window collapsed to 22 seconds. Access brokers now pre-stage the second actor’s tooling during the initial intrusion, so the handoff is instantaneous.

Consider what that does to your response plan. If your playbook assumes hours between compromise and escalation, it is planning around a window that no longer exists. Help Net Security’s coverage notes the median dwell time actually rose to 14 days in 2025, so defenders are getting less time to act and more time to bleed.

Where the Exploited Devices Actually Live

VulnCheck’s 2026 State of Exploitation report, also published on 23 March 2026, adds the device-level picture, and it is bleak.

42.5% of vulnerabilities exploited in 2025 affected end-of-life or likely end-of-life devices. Consumer routers and widely distributed networking products accounted for 56% of exploited edge device vulnerabilities. Among botnet-exploited vulnerabilities, 65% hit end-of-life products.

Read that again, because it reframes the problem. This is not primarily a zero-day story. It is an asset lifecycle story. Devices that should have been retired are still terminating production traffic, and attackers know it. Our post on modernizing cabling and infrastructure covers the physical half of the same neglect.

Why the Numbers Converge

Independent datasets rarely agree this closely, which is what makes the 2026 picture persuasive.

Mandiant works from incident response engagements. Verizon works from breach reports across thousands of organizations. VulnCheck works from honeypots and exploitation telemetry. Tenable and SentinelOne work from customer environments and actor attribution. Four different vantage points, four different collection methods, and one shared conclusion about where intrusions begin.

Furthermore, the Tenable and SentinelOne comparison found 79% convergence on the same vendor attack surfaces despite minimal overlap at the individual CVE level. Different sensors, different flaws, same handful of products. When that many independent measurements agree, treating network edge security as a secondary priority becomes very hard to defend in a board paper.

The Patch Gap That Undermines Network Edge Security

In network edge security, knowing which device is vulnerable turns out to be easier than getting it fixed. Joint research from Tenable and SentinelOne, published on 26 August 2026, quantifies the delay across 93 CVE-to-actor attribution pairs.

The Priority Paradox

High-priority CVEs carry a median remediation time of 146 days, against 122 days for everything else. In other words, the vulnerabilities you flagged as urgent get patched *24 days slower* than the ones you did not.

The reason is operational rather than negligent. Critical edge appliances carry the highest change-control friction, because rebooting a VPN concentrator disconnects the workforce. So the most dangerous devices are the hardest ones to touch, and the queue grows.

Exposure varies sharply by vendor. The same research found actively exploited CVEs present in 53.8% of monitored environments running F5, 24.9% for Fortinet, 24.1% for Ivanti and 18.6% for Check Point. Citrix customers showed the slowest remediation of all, at a median of 461 days.

KEV Is Necessary but Not Sufficient

Most vulnerability programs anchor on CISA’s Known Exploited Vulnerabilities catalog, and they should. It remains the authoritative record of what is being exploited in the wild.

However, VulnCheck found that only 23.7% of the vulnerabilities it observed under active exploitation appear in KEV. Treating KEV as the complete picture leaves roughly three quarters of observed exploitation unaddressed. Pair it with probabilistic scoring such as FIRST’s EPSS and with internet-scanning telemetry from organizations like the Shadowserver Foundation, which sends free daily exposure reports to network operators.

How a Modern Edge Compromise Actually Unfolds

The clearest public description of edge tradecraft is the multinational advisory on Chinese state-sponsored compromise of networks worldwide, co-authored by the NSA, CISA, FBI and DC3 alongside agencies from twelve other countries. It maps a pattern that criminal groups now imitate.

Step one: exploit a known CVE. The advisory names CVE-2023-20198, CVE-2024-3400 and CVE-2024-21887. None was a zero-day at the time of widespread use. Each had a patch available.

Step two: persist below the agent. Attackers modify access control lists, enable unauthorized SSH, and abuse virtualized containers such as Guest Shell. No endpoint agent runs there, so nothing alerts.

Step three: collect credentials at the choke point. Using the device’s own packet capture capability, they harvest authentication traffic including TACACS+. The edge device is the ideal listening post precisely because everything passes through it.

Step four: move and tunnel out. SNMP enumeration maps the internal network, then GRE and IPsec tunnels carry data out through traffic that looks entirely routine.

Notice that only step one involves a vulnerability. Everything after that uses features the device shipped with. We covered a comparable pattern in Interlock ransomware exploiting a Cisco FMC zero-day and in the actively exploited Fortinet flaw from 2020.

Why EDR Alone Cannot Deliver Network Edge Security

Most enterprises answer the network edge security detection question with the name of their EDR product. On the edge, that answer does not hold.

Edge appliances run vendor-locked operating systems that do not accept third-party agents. So the detection you rely on everywhere else is structurally absent at the one place attackers now prefer. Endpoint detection and response remains essential, yet it needs a network-side partner rather than being asked to cover ground it cannot reach.

Three controls fill that gap. First, configuration integrity monitoring that alerts on ACL, SSH and container changes. Second, centralized encrypted logging shipped off the device, so an attacker who clears local logs does not erase the evidence. Third, network detection that watches for unexpected tunnels and management-plane traffic, which is where Exodus ARIA ADR and Exodus NxtGen Firewall do their work.

Four Network Edge Security Myths That Cost Money

Every edge program runs into the same four objections. Each sounds reasonable, and each is wrong in a way the 2026 data now settles.

“We are behind a next-generation firewall, so we are covered.” The firewall is the target. Exposure research found actively exploited CVEs sitting inside a quarter to a half of monitored environments depending on vendor. A control that is itself unpatched protects nothing.

“Our devices are not interesting enough to attract state actors.” The multi-nexus finding kills this one. Twelve CVEs in the combined Tenable and SentinelOne dataset showed state-sponsored *and* criminal groups exploiting the same flaw independently. Ransomware crews reuse espionage tradecraft within weeks, so nobody stays uninteresting for long.

“We patch quarterly, which is fine for infrastructure.” A quarterly cycle against a 22-second handoff window is not a mismatch, it is a formality. Edge devices need an exception path, and that path must exist before you need it.

“Multi-factor authentication on the VPN solves this.” Strong authentication protects the login. It does nothing about a pre-authentication remote code execution flaw in the appliance that presents the login page. Both matter, but they defend different things.

Underneath all four sits the same assumption, namely that the edge is infrastructure rather than a security control. Once you treat every internet-facing appliance as a security product with a support contract and a firmware baseline, network edge security stops being an annual scramble. Our post on today’s software-defined networks not being future-ready makes the same argument from the architecture side.

A Nine-Point Network Edge Security Program

This is the network edge security sequence we run with clients. It is deliberately ordered so the cheapest, highest-impact steps come first.

Build a complete edge inventory. Every internet-facing appliance, with model, firmware version, support status and end-of-life date. Nothing else works without this.
Retire end-of-life devices first. Given that 42.5% of exploited vulnerabilities hit end-of-life gear, replacement often beats patching as a risk reduction per dollar.
Get management planes off the internet. No administrative interface should be publicly reachable. Use dedicated management VRFs and jump hosts, as the joint advisory recommends.
Disable what you do not use. Guest Shell, Smart Install, HTTP interfaces, unused SNMP communities. Every disabled feature is one fewer persistence option.
Ship logs off the box, encrypted. Centralized logging is the only reliable way to detect edge tampering, since local logs are the first thing an attacker edits.

Steps Six to Nine: Prioritize, Verify, Segment and Rehearse

Prioritize with three signals, not one. Combine KEV, EPSS probability, and your own exposure data. Any single source leaves gaps, as the 23.7% coverage figure shows.
Pre-approve emergency change windows for edge patching. The 24-day priority paradox is a process problem. Fix it by agreeing the maintenance window before the emergency, not during it.
Segment behind the edge. Assume the appliance falls. NIST SP 800-207 Zero Trust Architecture and our zero trust content security approach both start from that assumption, so a compromised gateway yields a segment rather than the network.
Rehearse a 22-second scenario. Run a tabletop where escalation is immediate. Most response plans quietly assume hours of grace, and that assumption no longer survives contact.

Map the whole program to NIST Cybersecurity Framework 2.0 so it reports cleanly to your board, and cross-check device hardening against the UK NCSC device security guidance.

Network Edge Security in the First Thirty Days

Keep the opening month small and concrete, because ambitious programs stall.

In week one, produce the inventory. Accept that it will be imperfect, and publish it anyway.

In week two, flag every end-of-life and out-of-support device, then price replacement. That list becomes your budget conversation.

In week three, close public management interfaces and disable unused services. This costs nothing and removes the most common persistence paths.

In week four, turn on centralized logging and agree the emergency patch window. Then report one number to leadership: the percentage of edge devices under active support with current firmware.

Five Questions to Ask Before Your Next Edge Refresh

Procurement is where most network edge security debt gets created, so these five questions belong in every evaluation.

What is the published end-of-support date for this exact model? Not the product line, the model. End-of-life gear carried 42.5% of exploited vulnerabilities, so this date is a security control.
How quickly have you shipped fixes for actively exploited flaws in the past two years? Ask for dates. Vendor responsiveness varies enormously, and the record is public.
Can the management interface be fully isolated from the data plane? If the answer requires creative network design, the product is fighting you.
What does the device log, and can it stream encrypted to our collector in real time? Logging that only lives on the appliance disappears with the first attacker who reaches root.
Will you support post-quantum key exchange, and when? Long-lived tunnels captured today stay readable later, a point we cover in Harvest Now, Decrypt Later.

Ask the same five of the appliances already in production. Most edge debt arrives through renewals and quiet refreshes rather than through deliberate new purchases, so the installed base usually answers worse than the shortlist.

Network Edge Security Risk by Sector

Network edge security exposure is not evenly distributed, because operational tolerance for downtime varies enormously.

Manufacturing and industrial. Dragos recorded 1,140 industrial ransomware incidents in Q2 2026, a 12% rise on the prior quarter, with manufacturing absorbing 747 of them. Plant networks tolerate downtime poorly, so edge patching slips further here than anywhere else.

Healthcare. Clinical continuity makes maintenance windows scarce, and remote access gateways for clinicians are a standing target. Segmentation matters more than patch speed when patch speed is genuinely constrained.

Financial services. Regulatory scrutiny of third-party and infrastructure risk keeps rising, and edge appliances sit squarely inside it. Our analysis of why big cybersecurity budgets still fail speaks directly to the spend-versus-control mismatch.

Telecom and service providers. The joint advisory named telecommunications infrastructure specifically. Router compromise here is not only a company problem, since it exposes the customers riding those circuits.

Public sector and suppliers. Procurement increasingly asks for firmware currency and support status by name. Our reporting on CISA adding actively exploited flaws to KEV tracks how quickly those expectations harden.

Across all of them, the financial stakes moved too. IBM’s Cost of a Data Breach Report 2026 puts the global average at $4.99 million, a 12% increase and a record high, while the World Economic Forum’s Global Cybersecurity Outlook 2026 documents widening capability gaps between organizations.

How ibm/SEIMless Approaches Network Edge Security

We are vendor-agnostic by design, and since 2001 we have chosen technology on fit rather than on partnership incentives. When exposure rates differ by a factor of three between edge vendors, that independence stops being a philosophical position and becomes a practical one.

Our network edge security work starts with the transport, because the edge is where the network meets everything else. Whether you run SD-WAN, MPLS, Ethernet, private line, wavelength services, dark fiber or wireless, each termination point is an edge device that needs an owner, a firmware baseline and a support contract. Teams evaluating MPLS replacement solutions should count the new appliances that decision introduces.

Enforcement runs through NxT-Gen Network Security Solutions, including Exodus NxtGen Firewall, zero trust content security and managed WAN optimization. Data protection sits underneath through Exodus Transparent Encryption and our Exodus Quantum-Resistant Networking portfolio, which protects data in motion across exactly the links an edge compromise would target.

Two related pieces round out the picture. Our post on agentic AI security meeting Q-Day explains why autonomous tooling shortens every timeline above, and the 2026 shadow AI playbook covers the governance gap that sits alongside this one.

Frequently Asked Questions

What counts as a network edge device?

Any internet-facing appliance that terminates sessions, holds credentials, or routes between trust zones. That includes firewalls, VPN gateways, SD-WAN appliances, load balancers, routers, remote access servers and file transfer appliances, at every site rather than only at headquarters.

Why is network edge security suddenly a priority in 2026?

Exploits became the leading initial infection vector at 32%, while email phishing fell to 6%. Attackers followed the weakest surface, and edge appliances offer internet exposure, credential access and no endpoint agent coverage.

Is this mainly a zero-day problem?

No. VulnCheck found that 42.5% of vulnerabilities exploited in 2025 affected end-of-life or likely end-of-life devices, and the major state-sponsored campaigns used CVEs that already had patches available.

Does our EDR cover edge appliances?

Generally not. Edge devices run vendor-locked operating systems that do not accept third-party agents, so coverage has to come from configuration integrity monitoring, centralized logging and network detection instead.

Is the CISA KEV catalog enough for prioritization?

It is essential but incomplete. Only 23.7% of vulnerabilities VulnCheck observed under active exploitation appeared in KEV, so combine it with EPSS scoring and your own exposure telemetry.

What single step reduces edge risk fastest?

Get management interfaces off the public internet. It costs nothing, takes days rather than quarters, and removes the access path most edge intrusions depend on.

Conclusion

The perimeter did not disappear. It changed shape, moved to every branch office, and stopped being covered by the tooling most enterprises trust. That is the whole network edge security problem in one sentence.

The 2026 evidence is consistent across independent datasets. Exploits lead at 32%, edge devices are where those exploits land, end-of-life hardware carries 42.5% of the exploited vulnerabilities, and the window between compromise and escalation is now 22 seconds. None of that requires a new product category to address. It requires an accurate inventory, a retirement budget, closed management planes and a maintenance window agreed in advance.

Network edge security rewards discipline over spending. The organizations that get this right are rarely the ones with the largest budgets. They are the ones that know exactly what is plugged into the internet, and who owns it.

Ready to find out what your edge actually looks like? Get started with ibm/SEIMless or contact our team for an edge inventory and exposure assessment. You can also review our reports, browse our partners, read the FAQs, or explore distributor opportunities.

Contact Us | Our Blog | Our Services | See Previous Post….

Shadow AI Is Now in 43% of Breaches: The 2026 Enterprise Playbook

by hannahadmin | Aug 28, 2026 | blog, cybersecurity, Enterprise technology, Next-gen Security solutions, Seimless

Shadow AI has become the fastest-growing security gap in the enterprise, and the 2026 numbers finally make the scale of it undeniable. IBM’s latest breach research puts unsanctioned AI tools inside 43% of security incidents. That figure more than doubled in a single year. Meanwhile, most organizations still have no process for approving, tracking, or revoking the AI tools their own employees use every day.

This is not a story about reckless staff. It is a story about a control gap. People adopt AI because it makes their work faster, and they reach for whatever tool is nearest when the sanctioned option does not exist. At ibm/SEIMless, we have watched the same pattern play out with cloud storage, then with messaging apps, and now with AI. The lesson repeats: you cannot secure what you have not inventoried.

This guide covers what shadow AI is, what the current data actually says, how it leaks information, what regulators now expect, and a practical program you can start this quarter.

What Shadow AI Actually Is, and What It Is Not

Shadow AI describes any artificial intelligence tool, model, agent, or AI-enabled feature that touches company data without security review, procurement approval, or governance oversight.

The definition sounds narrow. In practice it is very wide, because AI now arrives through four separate doors, and only one of them looks like a purchase.

The Four Faces of Shadow AI

Consumer chatbots on personal accounts. An analyst pastes a customer list into a free chatbot to reformat it. No contract governs that data. No log records the transfer.

AI features quietly added to approved software. Your sanctioned CRM ships an AI summarizer in a routine update. Nobody reviewed it, yet it now reads every record. This is the category most teams miss entirely.

Employee-built automations and agents. A finance lead wires an AI agent to a spreadsheet and an email inbox. The agent holds credentials, and no one has scoped them.

Browser extensions and plugins. Free extensions read page content by design. On an internal application, that means they read your data.

Notice what unites all four. None involves malice, and none triggers a purchase order. Consequently, none reaches the security team through the usual channels. Our post on how LLMs will improve network security explains the upside of AI in the enterprise; shadow AI is simply that same technology arriving without the guardrails.

The 2026 Numbers: Shadow AI Moved From Edge Case to Norm

The evidence base changed sharply this year. Three major studies now measure shadow AI directly rather than treating it as an anecdote.

IBM’s Cost of a Data Breach Report 2026, published on 29 July 2026, studied 602 breached organizations across 17 industries and 16 countries. It found shadow AI involved in 43% of incidents, up from roughly one in five the previous year. Furthermore, more than two-thirds of those organizations had no governance process to limit unauthorized AI deployment.

The same report puts the global average breach cost at $4.99 million, a 12% jump and an all-time high. AI-driven attacks rose 56%, led by deepfake impersonation and AI-enabled malware.

Netskope’s AI Report 2026 adds the usage picture. Only 56% of workplace AI users stay entirely inside organization-managed applications. Another 14% mix managed and personal tools, while 30% use personal accounts exclusively. In other words, nearly half of AI activity sits partly or wholly outside company control.

Verizon’s 2026 Data Breach Investigations Report rounds out the threat side. It reports that 15% of attack techniques are now bolstered by generative AI, and that 31% of breaches begin with software vulnerabilities, which have overtaken stolen credentials as the leading entry point.

What Shadow AI Costs When It Goes Wrong

Cost data from IBM’s earlier baseline research is the clearest picture available of shadow AI’s financial tail.

Breaches linked to shadow AI added as much as $670,000 to the average incident cost. Nearly two-thirds of those breaches exposed customer personally identifiable information. Intellectual property proved the most expensive category, at $178 per record.

One statistic stands out above the rest. Among organizations that suffered an AI-related breach, 97% lacked proper AI access controls. That is not a technology failure. That is an identity and permissions failure, and it is fixable.

Why the Governance Gap Persists

Ask any CISO why the gap exists and you get the same three answers.

First, procurement never sees the tool, because free tiers require no purchase. Second, network monitoring often misses it, since traffic to a major AI provider looks identical to ordinary web browsing. Third, and most importantly, the sanctioned alternative is either slower, worse, or missing altogether.

That third reason matters most. Employees do not route around controls for fun. They route around controls that cost them time.

Shadow AI Is Not Just Shadow IT With a New Name

Security teams reach for the shadow IT playbook first, and that instinct is only half right. The discovery methods transfer well. The remediation methods do not.

Shadow IT moved data to an unapproved location. You could usually find the file, delete it, and close the ticket. Shadow AI behaves differently in three ways that matter.

The data may not come back. A prompt sent to a consumer service can be retained, reviewed by humans, or used to improve a model. Deleting your local copy changes nothing about the copy that already left.

The exposure compounds over time. Model memorization means a snippet submitted today can surface in an output months later. Traditional shadow IT exposure was static, whereas this exposure has a long tail.

The tool acts on your behalf. An unapproved file-sharing service stored things. An unapproved AI agent authenticates, queries, writes, and sends. Therefore the blast radius is defined by permissions rather than by storage.

There is a fourth difference that is easy to miss. Shadow IT was mostly invisible to the vendor whose product it displaced, while shadow AI often arrives *from* the vendors you already trust. When a licensed application adds an AI assistant in a routine release, the shadow appears inside your approved estate. Our post on the five major impacts of machine learning models on data security covers that dynamic in more depth.

How Shadow AI Actually Leaks Enterprise Data

Understanding the mechanics helps you choose the right control. Shadow AI leaks data through five distinct channels, and each one needs a different answer.

Prompt-Side Leakage

This is the obvious one. A user pastes source code, a contract, a patient record, or a credential into a prompt. The data leaves your perimeter instantly.

Volume tells the story here. Netskope’s Cloud and Threat Report 2026 found that data sent to SaaS generative AI apps grew sixfold in a year, from roughly 3,000 to 18,000 prompts per month in the median organization. Around 3% of AI users generate an average of 223 data policy violations each month.

The Personal Account Problem

Enterprise AI agreements typically promise that your prompts will not train the vendor’s models. Consumer accounts frequently promise the opposite, or say nothing at all.

Encouragingly, the trend is improving. Infosecurity Magazine reported that personal-account usage among workplace AI users fell from 78% to 47% across a single year. Nevertheless, 47% is still nearly half your workforce operating outside contractual protection.

Agentic AI and MCP Widen the Channel

Chatbots read what you paste. Agents read what they can reach, which is a much larger set.

Netskope recorded downstream data policy violations doubling from 12 to 31 per week in the median organization, with top-quartile organizations climbing from 72 to 206. The report attributes that growth to agentic AI and to a fourfold increase in Model Context Protocol traffic. We covered the security implications of autonomous agents in our analysis of the agentic AI vulnerability exposed in ServiceNow and the malicious npm package that stole files from an AI user directory.

Model Inversion and Memorization

The subtlest channel runs in reverse. Attackers query a model to reconstruct the data it was trained or fine-tuned on.

NIST’s Generative AI Profile, AI 600-1, names data memorization explicitly, warning that models can leak, generate, or infer sensitive information about individuals. IBM prices the average model inversion breach at $6 million — higher than a conventional breach, because the exposed asset is usually the training corpus itself.

Third-Party and Supply Chain Exposure

The fifth channel is not yours at all. Your vendors, contractors, and managed providers use AI too, and their shadow AI becomes your exposure the moment they touch your data.

Consider a design partner summarizing your specifications in a consumer chatbot, or an outsourced support team pasting customer tickets into a free translator. No control you deploy internally will catch either one. Only contract language and vendor assessment will.

Third-party risk already dominates breach reporting, and AI widens it. Our coverage of the Ericsson service provider breach and the GlassWorm supply chain takedown shows how quickly a partner’s weakness becomes your incident. Add AI clauses to your standard agreements now, before renewal cycles make it awkward.

The Compliance Clock Is Already Running

Regulation caught up with shadow AI faster than most enterprises expected, and one date in particular lands this month.

Under the EU AI Act implementation timeline, most remaining provisions of the Act began applying on 2 August 2026. Member states must now maintain at least one national AI regulatory sandbox. A further milestone follows on 2 August 2027, when Article 6(1) obligations and legacy general-purpose model compliance take effect. If you process EU data or serve EU customers, ungoverned AI is no longer only a security problem.

Three frameworks now define what “reasonable care” looks like, and auditors increasingly expect at least one.

NIST AI Risk Management Framework, built on four functions: Govern, Map, Measure and Manage.
ISO/IEC 42001, the certifiable AI management system standard, published in December 2023.
NIST Cybersecurity Framework 2.0, which added a Govern function that maps neatly onto AI oversight.

For the threat side, OWASP’s GenAI LLM Top 10 for 2026, released on 3 August 2026, and the companion Top 10 for Agentic Applications give engineering teams a concrete checklist. MITRE ATLAS supplies the adversary tactics catalogue, while CISA’s artificial intelligence resources and the UK NCSC machine learning principles translate all of it into operational guidance.

Why Blocking Shadow AI Never Works

Every organization tries the block first. Almost every organization abandons it within two quarters.

The reason is simple. Blocking a domain does not remove the need that drove the employee there. It relocates the activity to a phone, a home laptop, or a personal browser profile, where you have no visibility at all. Consequently, you trade a monitored risk for an invisible one.

The World Economic Forum’s Global Cybersecurity Outlook 2026 frames the same tension at a macro level, describing accelerating AI adoption alongside widening capability gaps. Stanford HAI’s AI Index puts it more bluntly still, documenting a widening gap between what AI can do and how prepared organizations are to manage it.

So the goal is not zero AI. The goal is zero ungoverned AI. Those are very different targets, and only one of them is achievable.

A Seven-Step Shadow AI Governance Program

Here is the sequence we use with clients. It works because it starts with visibility and ends with an alternative, rather than starting with a ban.

Discover before you decide. Inventory AI usage from egress logs, SaaS management tooling, browser extension reports, and expense data. Include AI features inside tools you already own, since that category hides the most exposure.
Classify by data sensitivity, not by tool popularity. A niche tool touching patient records outranks a popular one touching marketing copy. Rank by what the tool can reach.
Fix access controls first. Recall that 97% of AI-related breaches involved missing access controls. Scope every AI integration to least privilege, use short-lived credentials, and log every call. Our zero trust content security approach applies directly.
Publish a short, readable AI policy. Two pages beats twenty. State clearly what data may go into which tier of tool, name the approved options, and explain the approval route. A policy nobody reads governs nothing.

Steps Five to Seven: Replace, Monitor, Repeat

Provide a genuinely good sanctioned option. This is the step that actually reduces shadow AI. If the approved tool is slower or weaker than the free one, employees will keep choosing the free one. Our Microsoft SaaS and DaaS and security as a service practices exist to close that quality gap.
Monitor prompts and outputs, not just domains. Domain blocking sees destinations. Content inspection sees data. Pair data loss prevention with Exodus ARIA ADR, endpoint detection and response and Exodus Transparent Encryption.
Re-run discovery every quarter. Shadow AI is not a project with an end date. New tools appear weekly, and vendors add AI features to existing products constantly.

For the infrastructure underneath this program, see our guides to enterprise IT infrastructure services and next-gen network security solutions.

What Good Looks Like in the First 90 Days

Programs stall when the first milestone is too far away, so keep the opening quarter deliberately small.

In weeks one to three, run discovery and produce a single list of every AI tool touching company data. Do not judge anything yet. Completeness matters far more than accuracy at this stage.

In weeks four to six, fix access controls on the ten highest-risk integrations. Scope permissions down, rotate long-lived credentials, and turn on logging. This is the step that moves the risk number most.

In weeks seven to nine, publish the two-page policy and name the approved tools. Announce it in plain language, and explain the approval path in a single sentence.

In weeks ten to twelve, stand up monitoring and book the next discovery run. Then report to leadership using one number: the share of AI usage now inside governed channels.

That final metric is the one worth tracking every quarter. It rises as your program works, and unlike breach counts, it does not require something to go wrong before it tells you anything.

Five Questions to Put to Every AI Vendor

Procurement language is your cheapest control, and these five questions surface most of what matters.

Do you train on our data by default, and can we contractually opt out? Get the answer in the contract, not in a marketing page.
What is your data retention period, and can we set it to zero? Retention you cannot configure is retention you cannot govern.
Which sub-processors see our data, and where do they operate? This drives your residency and EU AI Act position.
How do you scope and log agent permissions? If the answer is vague, assume the permissions are broad.
Will you support post-quantum key exchange, and on what timeline? Data captured today stays readable later, a point we cover in Harvest Now, Decrypt Later.

Ask these of your existing vendors too, not only new ones. Most AI functionality in your estate arrived through renewals rather than through fresh procurement.

Shadow AI Risk by Sector

Exposure varies with the data you hold and the rules you answer to.

Healthcare. Protected health information pasted into a consumer chatbot is a reportable disclosure in most jurisdictions. Clinical staff face heavy documentation loads, so the pull toward AI summarization is strong. Sanctioned tooling matters more here than anywhere else.

Financial services. Model risk management already governs algorithms in this sector, and shadow AI sits squarely outside it. Add customer PII exposure and the audit questions get pointed quickly. Our look at why big cybersecurity budgets still fail covers the spending-versus-control mismatch.

Manufacturing and engineering. Intellectual property carries the highest per-record cost in shadow AI breaches. A single design document in a prompt can outweigh a year of security spending. Third-party exposure compounds it, as the Ericsson service provider breach showed.

Legal and professional services. Privilege does not survive a prompt sent to an unvetted third party. Client confidentiality obligations make this the sharpest risk of all.

Public sector and defense suppliers. Procurement rules increasingly require documented AI governance. Our reporting on the Pentagon’s supply-chain risk designation for an AI vendor shows how fast that scrutiny is tightening.

How ibm/SEIMless Helps Enterprises Govern Shadow AI

We are vendor-agnostic by design, and since 2001 we have selected technology on fit rather than on partnership incentives. With every vendor now claiming AI governance capability, that independence matters more than it used to.

Shadow AI is fundamentally a visibility and identity problem, so we treat it as a network problem. Discovery runs across your wide area network, SD-WAN and business class internet egress points. Enforcement runs through Exodus NxtGen Firewall, zero trust content security and EDR.

Data protection layers underneath. Exodus Transparent Encryption and our Exodus Quantum-Resistant Networking portfolio protect data at rest and data in motion, while Exodus Key Management tracks the credentials your AI integrations depend on.

Finally, the sanctioned alternative has to be good. Our cloud services, Microsoft Azure, telecom services and document management practices give employees capable approved tooling, which is the only durable way to shrink the shadow.

Frequently Asked Questions

What is shadow AI in simple terms?

Shadow AI is any AI tool, model, agent, or AI feature that handles company data without security review or approval. It includes consumer chatbots, employee-built agents, browser extensions, and AI features switched on inside software you already license.

How common is shadow AI in 2026?

IBM found shadow AI involved in 43% of studied security incidents in its 2026 report, more than double the prior year. Separately, Netskope found that 44% of workplace AI users touch personal, unmanaged AI applications.

Is shadow AI worse than shadow IT was?

In one respect, yes. Shadow IT typically moved data to an unapproved location, whereas shadow AI can move data into a system that may retain it, learn from it, or expose it through later queries. The data does not simply sit somewhere new.

Can we just block AI tools at the firewall?

Blocking alone rarely works. Employees move the activity to personal devices where you have no visibility, so you exchange a monitored risk for an invisible one. Discovery plus a good sanctioned alternative outperforms blocking every time.

What does the EU AI Act require from us?

Most remaining provisions of the Act began applying on 2 August 2026, with further obligations arriving on 2 August 2027. If you handle EU data, you need documented AI inventories, risk classification, and oversight.

Where should we start if we have done nothing yet?

Run discovery, fix AI access controls, and publish a two-page policy. Those three steps take weeks rather than quarters and remove most of the immediate exposure.

The Bottom Line

Shadow AI is not a passing phase, and it will not resolve itself. Adoption is running ahead of governance in almost every organization, and the 2026 data now prices that gap precisely: 43% of incidents, a record $4.99 million average breach cost, and 97% of AI-related breaches traced to missing access controls.

The organizations that handle this well are not the ones with the strictest policies. They are the ones that see what is running, control what it can reach, and give people an approved tool worth using. Visibility first, identity second, alternatives third.

Ready to find out what is actually running on your network? Get started with ibm/SEIMless or contact our team for a shadow AI discovery and governance assessment. You can also review our reports, browse our partners, read the FAQs, or explore distributor opportunities.