by hannahadmin | Sep 22, 2026 | Compliance, Network Security, Seimless
Over the weekend of September 20, 2026, Amazon shut Meta’s new Muse personal AI agent out of Amazon.com. Shoppers who asked Muse to buy something got a blunt message: continued access by an unauthorized AI agent violates Amazon’s Conditions of Use. Headlines framed it as a retail turf war. For security leaders, it is something bigger: the first high-profile, consumer-scale collision over AI agent traffic — and a preview of decisions every enterprise will have to make about the autonomous software now knocking on its digital front door.
This post breaks down what happened, why the courts won’t settle it for you, what the numbers say, and how financial services, healthcare, and insurance organizations can build an AI agent traffic policy that is enforced at the network — not just written in a terms-of-service page.
What is AI agent traffic? AI agent traffic is network and web activity generated by autonomous AI software acting on a person’s or organization’s behalf — logging in, browsing, filling forms, calling APIs, and completing transactions. Unlike classic crawlers, AI agents often use real user credentials and mimic human browsing, which makes them hard to tell apart from people or attackers unless they identify themselves cryptographically.
What Happened: Amazon vs. Meta’s Muse, in Brief
Meta introduced Muse in September 2026 as a personal agent that “takes action”: it can open browsers, fill forms, send email with approval, and make purchases through Stripe Link. TechCrunch covered the debut on September 8. Within two weeks, GeekWire reported that Amazon had blocked it after first asking Meta to remove Amazon from the experience voluntarily.
Amazon’s stated objections are the ones security teams should notice:
- No self-identification. Amazon says Muse accessed the store without identifying itself as an agent or reaching any prior agreement.
- Credential custody. Amazon says the agent captures and stores customer credentials and, when instructed, can reach order history and other account data.
- Amazon’s position, as reported by TechCrunch, is that third-party apps that buy on a customer’s behalf “should operate openly.”
Meta’s side matters too. The company says Muse cannot see users’ passwords or payment methods; credentials sit in secure storage and are used for authentication without being exposed to the model. Meta also describes a dedicated secure VM, a separate “Sentinel” agent that approves internet-bound actions, and audit trails. Forbes and Bloomberg framed the standoff around commerce, and the money is real: Amazon’s advertising business depends on humans seeing sponsored placements, while Oppenheimer’s Jason Helfstein estimates Meta would need about 115 million subscribers at $20 a month to reach $28 billion in AI revenue — a target he doubts it will hit.
Both companies can be partly right. That is exactly the problem: when an AI agent shows up, the receiving system usually cannot verify either company’s claims in real time.
Why AI Agent Traffic Is a Security Story, Not Just a Retail Feud
Strip away the brands and you have three questions every CISO will face this year:
- Who is this? Is the session a human, a declared agent, a scraper, or an attacker using a stolen session token?
- On whose authority? Did the account holder actually delegate this action, and within what limits?
- Who holds the keys? Where do the credentials live, and what happens when that third-party vault is breached?
We call this the undeclared agent problem: software that uses a legitimate person’s identity but never announces that software, not a person, is at the keyboard. Undeclared AI agent traffic looks almost identical to account takeover (ATO). The same signals that flag fraud — a new device, headless browser fingerprints, machine-speed navigation — also flag helpful agents. Block too much and you break customer experience; block too little and you give attackers the perfect disguise.
We explored the inside-the-enterprise version of this in The Hidden Risk of AI-to-AI “Blind Agent Transfer”. The Muse episode is the outside-in version: agents arriving from someone else’s platform, carrying your customers’ credentials.
The Legal Backdrop: Why the Courts Won’t Manage AI Agent Traffic for You
Amazon has been here before. It sued Perplexity over the Comet browser’s shopping agent and won a preliminary injunction in March 2026. On August 4, 2026, the Ninth Circuit vacated that injunction. As Cooley’s analysis summarizes, the court held that when an agent’s communications route through the user’s own computer, it is the user — not the AI developer — who “accesses” the site under the Computer Fraud and Abuse Act.
The ruling builds on the Supreme Court’s narrowing of the CFAA in Van Buren v. United States (2021). It also left doors open: contract and tort claims survive, and agents that act more autonomously or talk directly to target servers could still face liability.
The practical takeaway for enterprises is simple. Anti-hacking law is a slow, uncertain backstop for AI agent traffic. Your terms of service state a policy. Your network and identity controls enforce it. Amazon didn’t wait for a court — it enforced at the edge.
AI Agent Traffic by the Numbers
The scale is no longer theoretical. The 2026 Thales (Imperva) Bad Bot Report, released April 29, 2026, found:
| Metric |
Figure |
Why it matters |
| Share of all web traffic that is automated |
Over 53% |
Humans are now the minority on the web |
| Growth in AI-driven bot attacks, year over year |
12.5x |
Attackers are adopting agents faster than defenders |
| Bot attacks aimed at APIs |
27% |
Agents skip the web page and go straight to the data |
| Share of bot attacks hitting financial services |
24% |
Banking is the top target |
| Account takeover incidents targeting financial services |
46% |
Credential-carrying traffic is the core risk |
Federal data tells the same story. The FBI’s 2025 IC3 Annual Report logged $20.877 billion in reported losses, including 22,364 AI-related complaints totaling $893.3 million. The FBI also issued a November 2025 account takeover fraud alert citing more than 5,100 complaints and over $262 million in losses in less than a year. When legitimate AI agent traffic and ATO traffic look the same, both numbers get harder to manage.
Two Directions of Risk: Inbound Agents and Outbound Agents
Inbound: agents at your front door
If you run a banking portal, a patient portal, a claims system, or a B2B ordering site, agents like Muse are coming whether you invite them or not. Customers will ask their assistant to “pay my premium,” “download my lab results,” or “dispute that charge.” Every one of those sessions is AI agent traffic using a real customer’s credentials.
Financial services has seen this movie. Screen scraping by data aggregators was supposed to give way to secure APIs under the CFPB’s Personal Financial Data Rights rule (Section 1033). That rule is now enjoined while the Bureau reconsiders it. In the meantime, agents are reviving the old pattern — credential-based access through the front end — at far larger scale.
Outbound: agents carrying your keys
The quieter risk is inside your own walls. An employee who connects a personal agent to a corporate mailbox, a SaaS admin console, or a vendor portal has just placed company credentials in a third-party vault you never assessed. That is shadow AI with a credit card attached. We have already seen attackers go after exactly these stores — see our coverage of a Python backdoor stealing browser and cloud credentials and fake résumés used for credential theft. A centralized agent credential store is an even richer target.
How to Identify AI Agent Traffic: From User-Agent Strings to Cryptographic Proof
User-agent strings and IP allowlists were never proof of identity; they are a label anyone can copy. The industry is moving toward cryptographic proof:
The direction is clear: AI agent traffic should declare itself, prove its operator, and carry a scoped, revocable delegation from a human who authenticated strongly.
A 7-Step AI Agent Traffic Governance Framework
- Decide your policy in writing. Allow declared agents, allow them only through an API, or block them. Choose per system: a public catalog and a wire-transfer page deserve different answers.
- Inventory where agents already touch you. Use web logs, WAF data, and endpoint detection to find headless browsers, automation frameworks, and agent-hosting IP ranges.
- Offer a front door. Give legitimate agents an authenticated API with OAuth-style scoped tokens, so they have no reason to scrape your UI.
- Require proof, not labels. Favor signed requests (RFC 9421 / Web Bot Auth) and verified operator keys over user-agent strings.
- Bind agents to scope and step-up. Agents may read a balance; moving money, changing a payee, or releasing records requires human step-up authentication.
- Govern outbound agents. Ban unmanaged agents from holding corporate credentials; route approved ones through enterprise identity and Security as a Service
- Log for accountability. Record agent identity, delegating user, scope, and action in tamper-evident logs, mapped to the NIST AI Risk Management Framework, the OWASP GenAI Security Project, and MITRE ATLAS threat techniques.
Why the Network Layer Is Where AI Agent Traffic Gets Decided
Amazon’s block worked because it happened before the agent reached the storefront. That is the lesson: policy that isn’t enforced in the traffic path is only a suggestion. This is the core idea behind NIST SP 800-207 zero trust architecture — and our own primer, What Is Zero Trust? — where every request is evaluated on identity and context, every time.
At ibm/SEIMless, we build that enforcement into the network itself through the Exodus portfolio:
There is also a quantum dimension. Agent identity is built on digital signatures and key exchange. Sessions recorded today can be decrypted later — the harvest now, decrypt later threat — and long-lived agent keys will need to move to NIST’s post-quantum standards such as FIPS 203 (ML-KEM). We covered that convergence in Agentic AI Security Meets Q-Day, and the federal deadlines in our Executive Order 14412 guide. The Exodus Quantum Resistant Network is designed so the trust you build for AI agent traffic today still holds after Q-Day.
What AI Agent Traffic Means for Financial Services, Healthcare, and Insurance
Financial services. Banks carry the heaviest share of bot and ATO attacks. The NYDFS Part 500 cybersecurity regulation now requires MFA for any individual accessing information systems — so an agent riding a customer or employee session must not become a quiet MFA bypass. Public companies should also weigh material agent-driven incidents against the SEC’s cybersecurity disclosure rules.
Healthcare. Patients will send agents to fetch records and book visits. The HIPAA Security Rule still requires access controls, audit controls, and person-or-entity authentication — obligations that apply no matter who, or what, is clicking.
Insurance. Quote, claims, and policy-change flows are prime targets for agent automation and for fraud hiding inside it. Scoped APIs and step-up rules for payout changes should come first.
Across all three, the network is where your answers become real. Solutions like SD-WAN alone don’t inspect identity — which is why we argued that SD-WAN is not ready for next-generation attacks and why network edge security is now the front line.
The Bigger Picture: Build Trust, Not Just Walls
AI agents will serve people well — in accessibility, in saved time, in better decisions. The goal is not to fear them. It is to make sure every agent that touches your business is honest about what it is, limited in what it can do, and accountable for what it did. Organizations that build that trust now will welcome the agent economy on their own terms. Those that don’t will be forced to choose between blocking customers and trusting strangers. As we noted when asking whether SaaS is dead, agents are becoming the new interface. Your security architecture has to be ready to meet them.
Frequently Asked Questions About AI Agent Traffic
Why did Amazon block Meta’s Muse AI agent?
Amazon says Muse accessed its store without identifying itself or reaching an agreement, and that it captured and stored customer credentials. Amazon displayed a notice that continued access by an unauthorized AI agent violates its Conditions of Use. Meta says Muse cannot see users’ passwords or payment methods.
Is it illegal for an AI agent to use a website on my behalf?
Not necessarily under federal anti-hacking law. In August 2026 the Ninth Circuit held that when an agent routes through the user’s computer, the user — not the AI developer — accesses the site under the CFAA. Contract and terms-of-service claims can still apply. This is not legal advice; consult counsel for your situation.
How can a company tell AI agent traffic from human traffic?
Behavioral signals like headless browsers and machine-speed navigation help, but they are unreliable. The stronger approach is cryptographic: signed HTTP requests (RFC 9421 and Web Bot Auth), verified operator keys, and scoped tokens issued through an authenticated API.
Should enterprises block all AI agents?
Usually no. Blanket blocking frustrates customers and pushes agents toward disguise. A better policy allows declared, verified agents through a scoped API, requires human step-up for high-risk actions, and blocks undeclared automation.
What is the risk of employees using personal AI agents at work?
Personal agents may store corporate credentials in third-party systems your security team has never assessed. That creates shadow AI exposure, weakens MFA, and concentrates keys in a vault that attackers will target.
How does quantum computing affect AI agent security?
Agent identity depends on signatures and key exchange that today use RSA and elliptic-curve cryptography, which large quantum computers are expected to break. Recorded sessions can be decrypted later, so long-lived agent keys and sessions should move to post-quantum cryptography and quantum-resistant networking.
Contact us | Our Blog | Our Services | See Previous Post….
by hannahadmin | Sep 18, 2026 | Compliance, Exodus QRN, PQC, Quantum Security, Seimless
Every quantum-security conversation eventually reaches the same fork in the road: QKD vs PQC. Do you protect your network with quantum physics — quantum key distribution over dedicated fiber — or with new mathematics, the post-quantum cryptography algorithms NIST standardized in 2024? For years, vendors on both sides blurred the answer. In 2026, the U.S. government stopped blurring it. The National Security Agency, the Pentagon, and the Office of Management and Budget have all chosen post-quantum cryptography as the foundation of the federal migration, and the Pentagon has formally barred QKD as a security mechanism for its systems.
That doesn’t make quantum networking a dead end. The same White House that set the PQC deadlines is funding quantum networks for sensing, timing, and distributed computing. For CIOs and CISOs in financial services, healthcare, insurance, and the defense supply chain, the practical question is not which camp wins. It is what to build first, what to buy with confidence, and what to hold as an option. This guide answers the QKD vs PQC question the way regulators now expect you to answer it.
Quick answer — QKD vs PQC: Quantum key distribution (QKD) uses the physics of single photons to share encryption keys over a dedicated optical link and detect eavesdropping. Post-quantum cryptography (PQC) uses new math problems — such as NIST’s ML-KEM and ML-DSA — that run in software and hardware on existing networks and resist attack by quantum computers. U.S. policy treats PQC as the required foundation. QKD, where it is used at all, is a supplementary layer on specific links and never a substitute for PQC authentication.
QKD vs PQC in Plain Terms: Two Very Different Answers to Q-Day
Both technologies exist because of one threat. A cryptographically relevant quantum computer running Shor’s algorithm would break RSA and elliptic-curve cryptography, the public-key math that protects nearly every VPN, TLS session, and digital signature in use today. Adversaries already collect encrypted traffic to decrypt later, the harvest now, decrypt later strategy that makes this a present-day risk.
How quantum key distribution works
QKD sends key material encoded in the quantum states of photons. Because measuring a quantum state disturbs it, an eavesdropper on the line introduces detectable errors. The two endpoints compare samples, discard compromised bits, and keep a shared secret. The idea is elegant: security rests on physics rather than on an assumption that a math problem is hard. As the U.S. Department of Energy explains in its primer on quantum networks, these systems rely on superposition, no-cloning, and entanglement.
How post-quantum cryptography works
PQC replaces vulnerable algorithms with ones built on problems that neither classical nor quantum computers are known to solve efficiently. In August 2024, NIST finalized its first three PQC standards: FIPS 203 (ML-KEM) for key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. In March 2025, NIST selected HQC as a backup key-establishment algorithm based on different math. PQC is software and firmware. It runs over the fiber, MPLS, broadband, and wireless links you already own.
What the NSA Says About QKD — and Why It Matters to Every Buyer
The clearest statement in the QKD vs PQC debate comes from the NSA. Its public guidance on quantum key distribution and quantum cryptography says the agency does not recommend QKD for National Security Systems and does not anticipate certifying or approving QKD security products unless its limitations are overcome. The NSA lists five of them:
- A partial solution. QKD produces keys but does not authenticate who is on the other end. You still need classical or post-quantum signatures to prevent a man-in-the-middle.
- Special-purpose hardware. QKD requires dedicated fiber or free-space optical equipment. It cannot be delivered as a software update or a network service.
- Cost and insider risk. Distance limits force “trusted relays,” secured facilities where keys exist in the clear and insiders become part of the threat model.
- Hard to validate. Real-world security depends on engineering, not theory. Hardware flaws can open side channels the physics never anticipated.
- Denial of service. The same sensitivity that detects eavesdropping lets an attacker disrupt the link simply by disturbing it.
The NSA concludes that post-quantum cryptography is the more cost-effective and easily maintained solution. For regulated enterprises, that statement matters beyond defense. Banking, healthcare, and insurance examiners anchor their expectations to NIST and NSA guidance, so a security architecture that cannot be mapped to those references is harder to defend in an audit.
The Pentagon Drew a Hard Line on QKD vs PQC
Defense leadership has gone further than advice. A November 18, 2025 DoD CIO memorandum, Preparing for Migration to Post Quantum Cryptography, states that components shall not use quantum confidentiality technologies — naming QKD, solutions that combine QKD with other key establishment, and quantum communications or networking — as a means of achieving confidentiality, authentication, or key distribution.
The Department of War then made the position permanent in its Post-Quantum Cryptography Strategy, announced in a June 23, 2026 release. The strategy repeats that QKD and quantum networking will not be used to achieve security, and adds a line every vendor should read twice: solutions that lack PQC authentication — migrating confidentiality only — will not be considered fully PQC. Its deadlines are blunt. All systems must support PQC by December 31, 2030 or be phased out, and all systems must use PQC by December 31, 2031. DefenseScoop reported that the strategy describes insecure communications in a quantum era as an “existential threat” to military operations.
If you sell to the defense industrial base, this is not an abstract debate. QKD does not count toward your PQC obligations, and a QKD-first architecture could be one you have to re-engineer.
OMB M-26-15 and Executive Order 14412: The Civilian Clock Is Running
On the civilian side, Executive Order 14412, signed June 22, 2026, set the federal PQC calendar we analyzed in our Executive Order 14412 deadline guide. Two days later, OMB issued Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography. It gives agencies 120 days — roughly October 22, 2026 — to submit PQC migration plans, calls for TLS 1.3 support by January 2, 2030, and targets completion of prioritized migrations by December 31, 2030.
Notice what the memo does not contain: any reference to quantum key distribution. The execution guidance is built entirely on NIST’s lattice-based and hash-based algorithms. The joint CISA, NSA, and NIST quantum-readiness factsheet takes the same path, focusing on inventory, vendor engagement, and PQC roadmaps. For federal contractors and the regulated industries that follow federal guidance, the QKD vs PQC decision has effectively been made for the compliance baseline.
Quantum Networking Isn’t Dead — Washington Is Funding It for Other Jobs
Here is the nuance most QKD vs PQC articles miss. The companion order, Executive Order 14413, Ushering in the Next Frontier of Quantum Innovation, directs agencies to prioritize research, testing, and evaluation of quantum sensing and quantum networking. Commerce is tasked with quantum-network-enhanced timing, Energy with networking for distributed quantum computing, and NASA with space applications.
The National Science Foundation describes the same direction in its June 2026 feature on quantum networks: linked sensors, GPS-free positioning, and pooled quantum processors, supported by regional test beds and quantum repeater research. So the federal message is consistent once you see it clearly. Quantum networks are a strategic technology for measurement and computation. For protecting data today, the government’s answer is post-quantum cryptography.
As FedTech Magazine’s 2026 federal QKD guide summarizes, CISA remains focused on the PQC migration and the DoD CIO’s post-quantum director has said QKD “does not meet our security requirements.” Infrastructure — dedicated links, endpoint hardware, and repeaters — remains the core obstacle for dispersed networks.
QKD vs PQC Side by Side: An Enterprise Comparison
| Factor |
Quantum Key Distribution (QKD) |
Post-Quantum Cryptography (PQC) |
| Security basis |
Physics of photons; security depends heavily on hardware engineering |
Math problems believed hard for quantum and classical computers |
| Authentication |
None on its own — needs signatures |
Built in (ML-DSA, SLH-DSA) |
| Infrastructure |
Dedicated fiber or free-space optics; trusted relays over distance |
Runs on existing networks, devices, and clouds |
| Standards status |
Not approved for NSS; barred as a security mechanism in DoD |
NIST FIPS 203, 204, 205 final; HQC in progress |
| Compliance credit |
Does not satisfy federal PQC mandates |
Required under EO 14412, M-26-15, and DoW strategy |
| Scale and cost |
Point-to-point; high cost per link |
Scales like software; cost driven by inventory and upgrades |
| Best fit today |
Research, specialized dedicated links, defense-in-depth where policy allows |
Every enterprise WAN, data center, cloud, and endpoint |
PQC has real costs too. Keys and signatures are larger — an ML-KEM-768 encapsulation key is 1,184 bytes versus 32 bytes for X25519 — which affects handshakes, constrained devices, and certificate chains. That is why crypto-agility, not a one-time swap, is the goal. Our certificate lifecycle management guide covers the operational side.
Where QKD Can Still Add Value — Honestly Scoped
The QKD vs PQC framing implies a winner-takes-all choice. It isn’t. Outside the Department of War’s systems and National Security Systems, an organization may choose to add physics-based key exchange as an extra layer — for example, between two owned data centers linked by dark fiber or wavelength services. Used this way, QKD is defense-in-depth on top of PQC, never a replacement for it.
Ask three questions before spending on it:
- Is PQC authentication already in place on this link? If not, fix that first. Keys without authenticated endpoints are an open door.
- Who controls the trusted nodes? Any relay where keys exist in the clear becomes a crown-jewel facility.
- What happens during an outage? If an attacker can force the link down, your failover path must be PQC-protected, not legacy RSA.
A PQC-First Roadmap for Financial, Healthcare, and Insurance Networks
For most enterprises, resolving QKD vs PQC comes down to sequencing. We recommend a five-step path aligned with the federal timeline and our post-quantum cryptography migration playbook:
- Inventory your cryptography. Identify every protocol, certificate, key, and library — including in medical devices, branch appliances, and third-party SaaS.
- Protect data in transit first. Harvest-now attacks target traffic, so start with quantum-resistant tunnels for data in motion across your WAN and SD-WAN, and plan the exit from legacy links through MPLS replacement.
- Centralize key management. Crypto-agility depends on knowing where keys live and rotating them on demand. Exodus Key Management provides centralized generation, distribution, storage, and rotation.
- Secure stored data. Long-retention records — loan files, patient histories, claims — need protection for data at rest and database-level transparent encryption.
- Evaluate QKD last, and only where policy permits. Treat it as an optional layer on specific dedicated links once PQC coverage is proven.
How Exodus QRN Resolves the QKD vs PQC Dilemma
ibm/SEIMless spent two decades as a vendor-agnostic integrator before becoming an OEM, and that history shapes how Exodus QRN approaches quantum security. The platform is built around crypto-agility — the memory, compute, and flexibility to add post-quantum algorithms as standards mature — with quantum random number generation for high-quality key entropy and centralized encryption and policy management across physical, virtual, and cloud environments.
Where a client has the dedicated optical infrastructure and a policy environment that allows it, quantum key distribution can be layered in. But our design principle mirrors federal guidance: post-quantum cryptography carries the compliance and authentication load, and nothing depends on QKD alone. Paired with the Exodus NxtGen Firewall and zero-trust content security, Exodus QRN protects today’s traffic while keeping your options open for tomorrow’s quantum networks. You can read more about the architecture in our Exodus QRN infrastructure overview.
We believe security is ultimately about people: patients whose records must stay private for decades, families whose savings depend on trusted banking rails, and teams who deserve infrastructure that won’t be obsolete before it is paid off. Choosing well now protects all of them.
QKD vs PQC: Frequently Asked Questions
What is the main difference in QKD vs PQC?
QKD uses the physics of photons to share keys over dedicated optical links. PQC uses new mathematical algorithms, standardized by NIST, that run on existing networks and devices and resist quantum attacks.
Does the NSA approve quantum key distribution?
No. The NSA does not recommend QKD for National Security Systems and does not anticipate certifying QKD security products unless its limitations — authentication, hardware, trusted relays, validation, and denial of service — are resolved.
Can the Department of War or its contractors use QKD for security?
Not as a security mechanism. The DoD CIO’s November 2025 memo and the 2026 DoW PQC Strategy state that QKD and quantum networking will not be used to achieve confidentiality, authentication, or key distribution.
Does QKD satisfy Executive Order 14412 or OMB M-26-15?
No. The federal migration is built on NIST PQC algorithms. OMB M-26-15 does not mention QKD, and agency migration plans are due about 120 days after June 24, 2026.
Is quantum key distribution completely obsolete?
No. Executive Order 14413 prioritizes quantum networking for sensing, timing, and distributed computing. Where policy allows, QKD can add defense-in-depth on dedicated links, but only on top of PQC.
Where should an enterprise start with post-quantum security?
Start with a cryptographic inventory, then protect data in transit with quantum-resistant networking, centralize key management, and secure long-retention data at rest. Evaluate QKD only after PQC coverage is in place.
Contact Us | Our Blog | Our Services | See Previous Post…
Related reading: The Impact of Quantum Computing on IPsec · IBM and Cisco’s Quantum Networking Partnership · Why Quantum-Resistant Networking Is a Business Necessity · All ibm/SEIMless insights
by hannahadmin | Sep 17, 2026 | blog, Quantum Security, Seimless, telecom, Zero Trust
Medical device cybersecurity has always been a race between patching and exposure. Now it has a second clock. The infusion pump, patient monitor, or imaging system a hospital buys this year may still be in clinical use in the late 2030s. By then, the RSA and elliptic-curve cryptography protecting it is scheduled to be retired. Healthcare leaders who plan only for today’s threats are buying devices that will fall short of tomorrow’s standards before they are fully paid off.
This guide explains the gap, what regulators already require, and how hospitals and manufacturers can close it. It starts from a simple belief we hold at ibm/SEIMless: protecting patient data is protecting people.
What is medical device cybersecurity? Medical device cybersecurity is the practice of protecting connected clinical devices, and the patient data and care they support, from unauthorized access, tampering, and disruption across the device’s full lifecycle, from design through retirement.
What is the cryptographic lifespan gap? The cryptographic lifespan gap is the number of years a device stays in clinical service after the encryption it relies on has been deprecated. For most connected devices bought in 2026, that gap is already more than zero.
Why Medical Device Cybersecurity Now Has a Quantum Deadline
In August 2024, NIST published its first three post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). In March 2025 it selected HQC as a backup encryption algorithm. Its draft transition plan, NIST IR 8547, proposes deprecating quantum-vulnerable algorithms after 2030 and disallowing them after 2035.
Federal policy has since set dates. Executive Order 14412, signed June 22, 2026, gives federal systems until December 31, 2030 to adopt post-quantum key establishment. We covered those milestones in our Executive Order 14412 deadline guide. The NSA’s CNSA 2.0 FAQ goes further on firmware. It urges signing systems to move first, because the code that checks a signature is often hard to update once a product ships.
That last point is the heart of the medical device cybersecurity problem. Enterprise laptops are replaced every few years. Clinical equipment is not.
The Cryptographic Lifespan Gap, Explained
Here is the arithmetic. A connected device bought in 2026 and kept for 10 to 15 years stays in service until 2036–2041. If the 2030 and 2035 dates in NIST’s draft hold, that device will spend years running cryptography that federal standards no longer accept.
| Device purchased |
Likely retirement |
Years past 2030 deprecation |
Years past 2035 disallowance |
| 2020 |
2030–2035 |
0–5 |
0 |
| 2026 |
2036–2041 |
6–11 |
1–6 |
| 2029 |
2039–2044 |
9–14 |
4–9 |
These ranges are illustrative, not a prediction for any single product. The pattern is the point: the later a hospital waits to demand post-quantum readiness, the wider the gap it signs up for.
An FDA-commissioned white paper from MITRE, Managing Legacy Medical Device Cybersecurity Risks, makes the same point. It warns that devices being purchased today can already meet the definition of a legacy device. It also notes a mismatch between how long hospitals keep equipment and how long manufacturers support it.
Why patient data makes “harvest now, decrypt later” worse
Attackers do not need a quantum computer today to benefit from one later. They can record encrypted traffic now and decrypt it once the math breaks. We explain the tactic in Harvest Now, Decrypt Later, and the underlying math in Shor’s algorithm explained.
Health data is an ideal target. A credit card can be canceled. A diagnosis, a genetic result, or a psychiatric history cannot. Data that stays sensitive for a patient’s lifetime needs protection that lasts just as long.
What the FDA Already Requires for Medical Device Cybersecurity
The FDA has steadily raised the bar. Since March 29, 2023, section 524B of the FD&C Act has required makers of “cyber devices” to include cybersecurity information in premarket submissions. The FDA’s cybersecurity FAQ defines a cyber device as one that includes sponsor-validated software, can connect to the internet, and could be vulnerable to cyber threats.
Manufacturers must now:
- Submit a plan to monitor, identify, and address postmarket vulnerabilities.
- Provide a software bill of materials (SBOM) covering commercial, open-source, and off-the-shelf components.
- Make updates and patches available to the device and related systems.
The FDA’s premarket guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, was updated on February 3, 2026 to align with the new Quality Management System Regulation. It lists cryptography among its recommended security controls. It also names secure and timely updatability and patchability as a core security objective. The agency’s postmarket guidance adds that networked devices need continual maintenance for their entire life.
Where the rules stop
None of these documents sets a date for post-quantum algorithms in medical devices. And as the GAO noted in GAO-24-106683, the 524B requirements do not reach back to devices already on the market before March 2023 unless a maker files a new submission. That leaves the installed base, which is most of what hospitals actually run, outside the new rules.
The Legacy Fleet Hospitals Already Own
Healthcare delivery organizations inherit the gap whether they planned for it or not. The FBI warned in a 2022 private industry notification that unpatched and outdated medical devices give attackers openings into hospital networks. The Health Sector Coordinating Council’s Managing Legacy Technology Security (HIC-MaLTS) guide describes the same shared burden between makers and providers.
The risk is not theoretical. In January 2025, the FDA issued a safety communication on certain Contec and Epsimed patient monitors. It pointed to CISA advisory ICSMA-25-030-01, which described hidden functionality and patient data being sent outside the care environment. The FDA’s advice was to cut the monitors off from the internet.
When the fix for a device is “disconnect it,” the network becomes the only control left. That is exactly where post-quantum protection can be added without waiting for firmware.
The stakes are high. An analysis of 2025 OCR data counted 710 large healthcare breaches exposing more than 61.5 million people’s records. Every one is listed on the HHS OCR breach portal. We saw the downstream damage in the Change Healthcare hack.
Why Post-Quantum Cryptography Is Hard on Medical Devices
If swapping algorithms were easy, the gap would close on its own. Four constraints make it hard.
1. Bigger keys and signatures
Post-quantum keys and signatures are much larger than the ones they replace. Per the FIPS 203 and 204 parameter sets:
| Function |
Classical (today) |
Post-quantum (NIST) |
| Key exchange public key |
X25519: 32 bytes |
ML-KEM-768: 1,184 bytes |
| Digital signature |
ECDSA P-256: about 64 bytes |
ML-DSA-65: 3,309 bytes |
On a battery-powered wearable or a low-memory controller, those extra bytes cost power, bandwidth, and storage.
2. Firmware roots of trust
Many devices verify updates with a key burned into hardware. If that check only understands RSA or ECDSA, no software update can teach it a new algorithm. This is why CNSA 2.0 favors the stateful hash-based signatures in NIST SP 800-208 (LMS and XMSS) for firmware signing now.
3. Validation and re-submission
Changing cryptography can mean new testing under the Cryptographic Module Validation Program and, for some changes, a new FDA submission. Our look at certificate lifecycle management and the FIPS 140-2 sunset covers why validation queues matter.
4. Protocols built for another era
Clinical networks still carry older protocols, flat VLANs, and vendor remote-access tunnels. We examined similar weak points in quantum computing’s impact on IPsec and why SD-WAN is not ready for next-generation attacks.
Regulatory Pressure Beyond the FDA
Medical device cybersecurity sits inside a wider compliance picture for providers:
A Medical Device Cybersecurity Roadmap for Hospitals
Hospitals cannot rewrite vendor firmware. They can control what surrounds it. A practical sequence:
- Inventory every connected device and its cryptography. Record the protocol, algorithm, certificate, and end-of-support date. A cryptographic bill of materials (CBOM) turns this into a living record.
- Score each device by its lifespan gap. Rank devices by planned retirement date, data sensitivity, and whether their cryptography can be updated.
- Segment clinical networks. Put devices in tightly scoped zones with zero trust policies, so a compromised monitor cannot reach the EHR.
- Wrap device traffic in quantum-resistant tunnels. Protect the paths between clinical zones, data centers, clouds, and remote sites so recorded traffic stays safe.
- Centralize key management. Rotate and govern keys in one place, rather than on thousands of endpoints.
- Watch device behavior. Flag devices that suddenly talk to unknown destinations, as in the Contec case.
- Protect the data at rest. Encrypt and back up the imaging archives and clinical data that devices feed.
- Write post-quantum language into contracts. Make readiness a buying requirement, not a wish.
Six questions to ask every device manufacturer
- Which algorithms does the device use for key exchange, signing, and storage today?
- Can those algorithms be changed by a field update, or are they fixed in hardware?
- What is your published roadmap for ML-KEM, ML-DSA, or LMS/XMSS support?
- Will you provide a CBOM alongside the SBOM?
- What is the end-of-support date, and what happens to security updates after it?
- Does the device support hybrid classical plus post-quantum modes during the transition?
What Manufacturers Should Build Into the Next Submission
For device makers, medical device cybersecurity is now a design decision with a long tail. The strongest submissions will show:
- Crypto-agility by design. Algorithms isolated behind interfaces so they can be swapped without a hardware change.
- Quantum-safe roots of trust. LMS or XMSS firmware signing, with ML-DSA as validated modules fit the device.
- Hybrid key exchange. Classical plus ML-KEM during the transition, so security never drops below today’s level.
- Honest lifecycle dates. End-of-support timelines that match how long hospitals actually keep equipment.
- A CBOM next to the SBOM. Buyers increasingly need to see cryptography, not just components.
How ibm/SEIMless Helps Close the Medical Device Cybersecurity Gap
Our view is simple: the fastest way to protect devices you cannot change is to protect the network around them. That is the thinking behind our Exodus QRN quantum-resistant networking suite.
Because this protection runs at the network layer, it does not depend on a device maker shipping new firmware. Hospitals can start with their highest-risk paths this quarter, then extend coverage as budgets allow. For the full migration picture, see our post-quantum cryptography migration playbook and network edge security in 2026. For AI-driven clinical workflows, our analysis of blind agent transfer applies to healthcare just as much as finance.
Medical Device Cybersecurity FAQ
What is medical device cybersecurity?
Medical device cybersecurity is the protection of connected clinical devices, and the patient data and care they support, from unauthorized access, tampering, and disruption across the device’s full lifecycle, from design through retirement.
Does the FDA require post-quantum cryptography in medical devices?
Not by a specific date. Section 524B requires cybersecurity information, an SBOM, and a vulnerability plan for cyber devices, and FDA guidance recommends strong, updatable cryptography. It does not yet set a deadline for post-quantum algorithms.
What is the cryptographic lifespan gap?
It is the number of years a device stays in clinical use after the encryption it relies on has been deprecated. A device bought in 2026 and kept 10 to 15 years may run six or more years past NIST’s proposed 2030 deprecation date.
Can hospitals protect legacy medical devices that cannot be updated?
Yes, with compensating controls. Segmentation, zero trust policies, behavior monitoring, and quantum-resistant encryption of network paths protect device traffic without changing device firmware.
Why is health data a target for harvest-now, decrypt-later attacks?
Health information stays sensitive for a patient’s lifetime. Attackers can record encrypted traffic today and decrypt it once quantum computers can break RSA and elliptic-curve cryptography.
What should hospitals ask device manufacturers about quantum readiness?
Ask which algorithms the device uses, whether they can be updated in the field, the vendor’s roadmap for ML-KEM, ML-DSA, or LMS/XMSS, whether a CBOM is available, and the end-of-support date.
Protect Patients Before Q-Day Arrives
Every connected device in your hospital carries a patient’s trust. ibm/SEIMless and Exodus QRN help healthcare, financial, and insurance organizations close the medical device cybersecurity gap at the network layer, without waiting on firmware. Let’s map your highest-risk device paths together.
Contact Us | Our Blog | Our Services | See Previous Post
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.
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
More resources: About ibm/SEIMless · FAQs · Blog · Agentic AI security meets Q-Day
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:
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…
