Revolutionary Information

Every router, camera and smart plug sold in the United States should be legally required to carry a password unique to that unit, or make you set your own, before it touches your Wi-Fi. Britain has enforced exactly that default password ban since 29 April 2024. America chose a sticker. The standard objection says a voluntary label lets shoppers reward careful makers without Washington writing firmware rules. It sounds reasonable, until you see what the sticker has done since.

Why a default password ban beats a label

A ban beats a label because it protects the buyer who never reads packaging, never registers the device and never changes a setting, while a label protects only the shopper who already knows to look for it.

The British version, set out on GOV.UK's product security regime page, is blunt: passwords must be unique per product or set by the user. Makers must also publish a route for reporting security bugs and say how long they will ship security updates. A British buyer gets that protection without knowing the law exists, which is the whole point of a rule.

America took the other road. The FCC approved the US Cyber Trust Mark on 14 March 2024 as a voluntary label, CyberScoop reported, so a US shopper gets password protection only when a maker opts in. Its lead administrator, UL Solutions, then withdrew on 19 December 2025 amid an FCC probe into its China ties, says Cybersecurity Dive. The FCC named the ioXt Alliance in its place on 13 April 2026, Broadband Breakfast reported, and won't pay for the job. By my count, the label shoppers were told to trust sat with nobody in charge for nearly four months.

Washington has been here before: its memory safety roadmap deadline for critical-infrastructure software carried no penalty and passed quietly. Europe binds vendors instead, as the Cyber Resilience Act's 24-hour vulnerability warning shows. Four figures from GOV.UK, the PSTI Act 2022 and Broadband Breakfast show the gap.

A fine pegged to worldwide turnover is too big for a global router brand to treat as a cost of selling in Britain, so the cheap answer is one firmware build for every market. You just can't tell from a US box which makers did it.

Does the UK ban default passwords on smart devices?

Yes, the UK has banned universal default passwords on consumer connected devices since 29 April 2024, requiring each product to ship with a unique password or make the buyer set one, under the Product Security and Telecommunications Infrastructure regime.

The table sets that law against the US label, read as a buyer standing in a store.

Read down the right-hand column: the label helps only buyers who already do the work. The first-row fine comes from the PSTI Act 2022; the 115-day gap is my arithmetic from the reported dates above.

Do routers have to come with unique passwords?

Only in some places: in Britain since April 2024, in California and Oregon since 2020, and across the EU from December 2027, while a router sold in the other 48 US states can still legally share one factory password.

California's SB-327, operative since 1 January 2020 (as of 2020), demands a password "unique to each device manufactured" or one the user creates. Oregon passed a near-copy. The EU's Cyber Resilience Act, on EUR-Lex, requires a secure by default configuration once its main obligations apply on 11 December 2027. So the "too costly" objection collapses: the engineering exists, and the biggest US state has demanded it for years.

The second objection calls default passwords a niche consumer worry. CISA disagrees. In December 2023 (as of 2023) its Secure by Design alert urged makers to drop default passwords after attackers reached Unitronics controllers at US water facilities; CyberScoop reported their factory password was 1111, so one shared login opened every identical unit. The federal security agency called it a manufacturer failure in writing, then only asked nicely. As with post-quantum migration deadlines, guidance without teeth moves at the pace of the slowest vendor.

One grey area remains, and this is opinion: should a federal rule reach devices already in homes? I'd cover new sales only, because retroactive rules invite lawsuits that stall everything. Watch-outs meanwhile:

• A Cyber Trust Mark helps, but its absence proves nothing.
• An app-based setup can leave the local web login on its factory value.
• Marketplace imports may follow no national rule.

So here's the decision. If you're in the US, treat the label as a bonus and the password check above as the real test, and this week log in to your own router and replace any password printed in its manual. Then tell your representative that Britain already proved the rule costs makers almost nothing.

Here is the rule. Under the Product Security Bad Practices guidance from CISA and the FBI, a maker of software used in critical infrastructure that had no published memory safety roadmap by January 1, 2026 is, in the agencies' own word, "dangerous". The date came and went. Your firewall vendor, your hospital's imaging supplier, the firm behind your water utility's control panels: none of them owed you a thing when it passed.

The flaw is in the rule. The same document says it "is non-binding" and "imposes no requirement", so the risk of a missing plan sits with you, the customer. It should be compulsory. And the standard objection, that leaving C and C++ is too slow and too costly, no longer survives the data.

Is CISA's memory safety guidance mandatory?

No, CISA's memory safety guidance is voluntary: the agencies call a missing roadmap dangerous for critical-infrastructure software, but attach no fine and no procurement ban, so a vendor that ignored the January 2026 date faces nothing.

Washington has stayed in that register. A June 2025 NSA and CISA information sheet on memory safe languages (Rust, Go and others that stop code touching memory it does not own) says the agencies "urge organizations to consider whether adopting MSLs is practical for their circumstances." That hands every vendor two exits, "consider" and "practical". A buyer waiting for a federal push is waiting for something the government has said, in writing, it will not do.

Other regulators have been less shy. Europe wrote vulnerability handling into law, down to the 24-hour exploited-vulnerability warning the Cyber Resilience Act demands. Even NIST put calendar years on its post-quantum migration deadlines. Memory safety, the older and better-understood problem, got an adjective.

Is Rust really safer than C++?

Yes, by a margin that ends the argument. A November 2025 Google report, Rust in Android, found its roughly 5 million lines of Rust running at about 0.2 memory-safety vulnerabilities per million lines, against roughly 1,000 in its C and C++, a reduction Google puts at more than 1,000x. That kills the excuse that safer languages just move bugs elsewhere.

But the objection was always about cost: rewriting slows teams, and ship dates pay salaries. Four numbers test that. Google's Android data supplies two, measured on changes of comparable size. MITRE's CWE Top 25, released in December 2025, supplies a count of memory errors among the most dangerous weaknesses. The calendar supplies the last.

Show the rollback figure to a sceptical finance director. A rollback is a release pulled after shipping, usually an outage and a lost weekend. Fewer of those means the cost objection runs backwards.

With no regulator compelling a plan, your contract is the only lever left.

What a required memory safety roadmap changes for buyers

Requiring the plan turns a vendor's vague intention into a dated, auditable commitment that covers its riskiest code first, which gives a buyer something to enforce at renewal instead of a hope.

The flaw-rate row is my arithmetic, not Google's: Android's measured densities scaled to a 100,000-line component. At those rates a new C++ service carries latent memory flaws in triple figures, and the Rust version most likely none.

Where a compulsory roadmap gets hard

A compulsory plan gets hard in two places: products close to retirement, which the guidance already exempts, and vendors who publish a roadmap with no dates in it, which satisfies the letter while changing nothing.

Do software makers have to stop using C and C++ by 2026?

No. The CISA and FBI guidance asks existing products for a plan, not a rewrite, and only calls new critical-infrastructure product lines in C or C++ dangerous where a memory-safe alternative exists. I'd go further than CISA, or at least put it more bluntly: a roadmap without a year beside each component is a brochure.

The unresolved question, in my opinion, is embedded firmware. A substation controller will not be rewritten, and a plan for it may mean little beyond the next model. Newer guidance shares the gap, such as the NSA's May 2026 advisory on MCP security for AI agents: sound advice, no teeth. Watch for:

• Goals with no year per component.
• Memory-safe claims covering only new features.
• An end-of-support date just inside the exemption.
• Sandboxing sold as a substitute, not a stopgap.

If two of those are true, stop waiting for Washington. This week, email the vendor asking for its published plan and support end date, and tell procurement that renewal now depends on a dated commitment, cryptographic code first. Require it yourself, because nobody else will.

Here is the rule. Since 11 September 2026, any company selling software or connected hardware in the European Union that learns one of its products is being actively exploited has 24 hours to send an early warning to the authorities, and 72 hours to follow it with a full notification. That is CRA reporting, set out in the European Commission's guidance on the Cyber Resilience Act, and it is already live. A vendor in Austin that sells the same router in Berlin and Boston now owes Berlin a warning. Boston gets nothing.

That gap should close by law, and the usual objection is mostly answered by how the rule is written.

Why CRA reporting should be the global floor

A vendor knows first when its product is being exploited, so the duty to warn belongs with the vendor, and a rule that protects only EU customers leaves every other buyer of the same product exposed.

The manufacturer sees the crash reports, the researcher emails and the telemetry spike days before customers notice anything. The Act makes that knowledge travel: manufacturers must also inform impacted users, according to Hogan Lovells' 11 September 2026 briefing. An EU hospital running a VPN appliance gets told. A clinic in Ohio running the identical box does not.

The American answer is thinner. CIRCIA puts the reporting duty on critical-infrastructure operators, the victims, not on the vendor whose code let the attacker in. CISA's Secure by Design pledge is voluntary, so a US buyer holds no enforceable promise unless it sits in the contract. Treating a pledge as a rule is outdated advice.

Anyone who tracked the DPDP consent manager deadline in India or post-quantum migration deadlines under NIST IR 8547 knows the pattern: a regulator sets a clock, and vendors discover how little of their process was built for one.

Run the clock on a real calendar. Confirm exploitation at 5pm on a Friday and the early warning is due by 5pm Saturday, the full notification by 5pm Monday. That is our own arithmetic, and it means someone with authority to file must be reachable all weekend. The four numbers below, from the Commission and Article 64 of the Act, decide whether vendors take that seriously.

The revenue-linked ceiling is what changes behaviour at large vendors. A flat cap is a budget line; a share of global revenue grows with the company, so the suppliers in the most networks carry the steepest exposure.

Does the Cyber Resilience Act apply to US companies?

Yes, the Cyber Resilience Act applies to any manufacturer placing products on the EU market, wherever it is based, so a US vendor selling into Europe already owes EU buyers warnings its home customers never receive.

US figures below come from Ballard Spahr's Byte Back analysis of CIRCIA (February 2026) and CISA's pledge page.

The vendor builds the triage desk for Europe anyway, so American customers pay for output they never see. Vendors treating 2027 as the start date have the calendar wrong.

Won't a 24-hour rule crush small vendors?

No, because the 24-hour step is an early warning to a national security team, not a public disclosure or a finished report, and the fuller detail follows on a structured, longer schedule.

At its strongest, the objection says a ten-person firm has no security team and a panicked filing could leak. Filings go through ENISA's Single Reporting Platform to the CSIRT of the manufacturer's main establishment, so the warning never touches the open internet. Attackers learn nothing from a message they cannot read.

The burden is real but scoped: a written threshold for "actively exploited" and a named Sunday filer. Plus a rehearsal. Two, honestly, because the first always finds the gap nobody wrote down. AI tooling vendors have more ground to cover, with flaws surfacing in MCP servers flagged in the NSA's advisory and in AI agent credentials nobody has inventoried.

The genuine grey area is the word "aware". In our view the clock should start at credible evidence of exploitation, not legal sign-off, but enforcement will settle it. Watch for these:

• Community-maintained components sit outside the clock until open-source stewards join.
• Severe incidents run a different final-report schedule, so check which your contract names.
• US buyers hold no right to the EU notice, even for identical firmware.

Do not wait for Washington. This week, pull your three largest software contracts and add one clause: the vendor notifies you within 24 hours of confirming active exploitation, on the same terms it already owes EU regulators. A vendor that refuses a promise it already keeps in Europe has told you what you need to know.

Related: why a memory safety roadmap should be compulsory for software vendors

Related: why a compulsory default password ban beats a voluntary label

Your consent flow works. A user taps accept, a row lands in your database, marketing gets its audience, and nobody thinks about it again. Now picture a platform your company has never integrated with, never signed a contract with, sending a withdrawal instruction on that same user's behalf and expecting your systems to honour it. That is the shape of the DPDP consent manager deadline landing on 13 November 2026. Most Indian data teams are still treating consent as something they own, when the law is about to treat it as something they receive.

Why the DPDP consent manager deadline lands early

The DPDP consent manager deadline lands early because your obligation is not to register a consent manager, it is to accept instructions from one, and that capability takes far longer to build than a vendor contract takes to sign.

Read the commencement schedule and it looks generous. MeitY notified the Digital Personal Data Protection Rules, 2025 on 13 November 2025. Rule 4 and the First Schedule, which carry the consent manager machinery, take effect exactly a year later. The operative duties on data fiduciaries wait until 13 May 2027. Eighteen months of runway. Plenty of time.

That reading is wrong, and it is the most common mistake in Indian compliance roadmaps right now. The 2027 date governs what you must tell people. The 2026 date governs what your systems must be able to hear. Those are different engineering problems, and the second one is harder, because it means an external party you did not choose gets to change the state of a record inside your platform. Anyone who has watched India's telecom sector fight over whether operators should display verified KYC names to the people they call already knows how slowly identity plumbing moves once it has to work across companies.

What is a consent manager under the DPDP Act?

A consent manager is an Indian-incorporated company, registered with the Data Protection Board, that gives a person one interface to grant, review, manage and withdraw consent across every business holding their data.

The First Schedule sets the bar deliberately high. The applicant must be incorporated in India. It must hold a minimum net worth of two crore rupees. Personal data routed through its platform must not be readable by it, which rules out the obvious architecture where a broker sits in the middle and inspects payloads. Consent records must be retained for seven years. Together those conditions describe an entity closer to a depository than to a SaaS product, and the capital test alone will keep the field small. Four numbers frame the problem.

The third cell is the one that should bother you. The Board is established in law under Section 18 of the Act, and MeitY has invited applications for its Chairperson and Members, with a search panel headed by the Cabinet Secretary. It is not fully constituted. No registry exists, so no company has been registered to do the job the rule assumes will be done. Meanwhile the DPDP Act's own schedule of penalties sets a ceiling of 250 crore rupees for a single failure to take reasonable security safeguards, and that ceiling is not waiting for anyone to be appointed. The same pattern shows up in AI agent governance, where the enterprises that moved before the rules landed are the ones now setting the terms.

Key highlights: what switches on, and when

India's DPDP Rules, 2025 commence in three tranches between November 2025 and May 2027, and only the consent manager tranche carries a build requirement that reaches outside your own systems.

The table below is the version of the schedule worth pinning above a sprint board, because it separates dates that create paperwork from dates that create engineering. Two of these rows describe conditions, not deadlines, and those are the ones that decide your architecture.

Rows four through six are the ones your architects should argue about. Eligibility decides whether your current privacy vendor can hold the role at all. Data blindness decides your integration shape. Retention decides the storage tier, and seven years is long enough that the answer is probably not your transactional database.

Do Indian companies have to use a consent manager?

No, a data fiduciary is not required to appoint a consent manager, but it must be able to receive and act on consent given, reviewed or withdrawn through one, which makes the integration mandatory even when the appointment is not.

This is where the common advice goes wrong. Plenty of teams have filed the consent manager work under procurement, expecting a vendor to arrive in 2027 with a connector. That gets the direction of the obligation backwards. The consent manager works for the individual, not for you. When it sends a withdrawal, your platform is the party that has to prove it acted, and proving it means an auditable trail that survives seven years and several system migrations. This is the same long-horizon storage problem that shows up in harvest now, decrypt later planning, where data you keep for a decade has to survive threats that do not exist yet.

What happens if no consent manager is registered by November 2026?

Nothing visible happens, and that is the trap. My read is that a quiet Phase 2 will be treated by most boards as evidence that the whole thing slipped, and the build will be deferred into the same quarter as the May 2027 duties. That is a bad bet. The Board can be constituted in weeks once appointments clear, registrations can follow quickly after that, and the first fiduciary asked to honour an external withdrawal will not get a runway. Watch for these before you defer:

• Legacy consent captured before the Rules, with no purpose string attached, which cannot be mapped to a machine-readable record.
• Withdrawal propagation that stops at the primary database and never reaches warehouses, exports, ad platforms or vendor copies.
• Consent state held in a table with no history, so you can show what is true today but not what was true on the day of a complaint.
• Vendor contracts that treat consent as your problem, with no obligation on the processor to accept a withdrawal signal you pass down.

Pick the ingestion endpoint and the audit log first, because both are slow and neither depends on a registry existing. The registry is the visible part. The unglamorous part, and honestly the part that will eat your quarter, is propagation. Start the design review this month, freeze it by mid-October, and let the Board catch up to you.

A developer at a mid-sized fintech wired a calendar tool into an internal agent on a Thursday afternoon. It worked on the first try. Nobody asked which server that tool actually lived on, who published it, or what else it could reach once the agent handed over a token. That connection is now one of the shortest paths into the company's data, and nobody logged it as a change.

Why It Matters

The standard advice right now is to start with identity. Give every agent a verifiable name and scope what it can touch. That advice is correct, and it is also about a year behind where things are actually breaking. An agent with a flawless identity that calls a compromised tool server is still an agent shipping your data somewhere it should not go. Giving every AI agent a verifiable identity answers who is acting. It says nothing about what sits on the other end of the connection.

Model Context Protocol is the plumbing. It standardises how an agent discovers a tool, calls it, and gets structured results back, which is precisely why it spread so quickly and precisely why it became the weak joint. A July 2025 internet scan cited in the Cloud Security Alliance's May 2026 research note counted 1,862 publicly reachable MCP servers running with no authentication at all. Not sitting misconfigured behind a gateway. Just open.

The NSA put its own reading on paper. Its Cybersecurity Information Sheet on MCP security design, version 1.0, published May 2026, states that the protocol's proliferation has outpaced the development of its security model, then sets out why: unsanitised inputs reaching execution environments, no role-based access control, serialization without schema enforcement, optional authorization with loose token lifecycles, and audit logging that varies wildly between implementations. None of that is exotic. Those are the basics, missing.

Four numbers frame how large this is, and not one of them describes a single vendor's bug.

The SDK ratio is the one that should change how you triage. When the defect sits in the reference implementations for every supported language, patching your own server code buys you nothing, because the weakness arrived with the library rather than with your developer. That converts an application fix into a dependency inventory problem, and most teams do not have that inventory in any usable form.

What the Record Actually Shows

Strip out the vendor commentary and a short, unflattering timeline is left. Documented incidents, a government advisory, a spec rewrite, and a disclosure process that moved at the speed of an open source side project rather than of critical infrastructure.

The through line is that every one of those rows was public before most security teams had MCP on a risk register. The information was never the bottleneck. Ownership was, because connector sprawl grows inside engineering while the risk lands on security, and the two functions were looking at different dashboards.

Four publicly documented MCP failures between April 2025 and November 2025, escalating from one product's cross-organisation data leak to remote code execution chained across connected servers.

Friction Points

The 2026-07-28 rewrite is a genuine improvement, and it also demonstrates something uncomfortable about protocol security. Going stateless closed session hijacking and stopped servers from pushing unsolicited prompts at clients. In exchange, Akamai's threat research team, through senior director Maxim Zavodchik, flagged a fresh set: predictable tracking identifiers that allow cross-tenant workflow hijacking, header misuse enabling desync, stored cross-site scripting through MCP Apps as first-class extensions, and hit-and-run denial of service where a client kicks off an expensive long-running task then vanishes. The spec authors did the right thing here, or most of the right thing, anyway.

Budget is the quieter problem. Security teams already carry one long-horizon cryptographic project in post-quantum migration deadlines, and connector inventory work competes for exactly the same small pool of people who understand both the crypto and the pipelines. Something gets deferred. It is usually the one without a regulator attached to it, which right now is this one.

Here is the piece nobody has solved, and I do not believe the specification can solve it alone: signing a tool description only helps if some body governs the registry vouching for the signer. No such governance exists today. My honest read is that the trust anchor question gets settled by a bad incident rather than by a working group, and that the organisations who inventory early will simply be the ones not writing an incident report that quarter.

• Any MCP server that answers without authentication belongs in incident response today, not in next quarter's backlog.
• Tokens minted under the old lifecycle assumptions should be rotated rather than grandfathered into the stateless model.
• Header mapping is the shortcut that looks harmless in code review, which is how secrets end up in MCP-Method and MCP-Name.
• Tool descriptions are attacker-controlled text. Filter each tool's output before it reaches the next tool.

Go find out how many MCP servers your organisation is actually running, counting the one a developer stood up for a demo in March and never took down. Then check which of them accept a connection without asking who is calling. That inventory is a morning's work for one engineer, and every other recommendation in this article is unactionable until it exists.

Keep reading

• AI Agent Governance Decides Which Enterprises Win in 2026
• The DPDP Consent Manager Deadline Trap
• Quantum Computing Explained for Business Leaders in 2026

Related: CRA reporting now forces software vendors to flag exploited flaws within 24 hours

At 2:14 on a Tuesday morning, an internal agent at a mid-sized logistics firm opened a support ticket, pulled a customer export, and pushed a config change to staging. Every one of those actions was permitted. Nobody could say who permitted them. The token it used belonged to a service account created in 2023 by an engineer who left the company in 2024, and the audit log recorded the actor as "automation-prod-07".

That is not a security failure in the way most boards understand the phrase. Nothing was breached. The system worked exactly as configured. It is an accountability failure, and it is now sitting inside a standards process at NIST rather than inside a vendor pitch deck.

Why this matters now

The industry already solved machine identity once. Workloads got certificates and CI runners got short-lived tokens, and everyone quietly agreed that a long-lived API key sitting in a repository was embarrassing. That model holds because a workload does one thing forever. An agent does not. It decides. It picks which tool to call and when to escalate. The thing it decides to do at 2am was not in the ticket that authorized it.

So the common advice, which is to give each agent a service account and move on, is wrong. Not slightly wrong. A service account answers "what is running." Agent identity has to answer four questions instead, and NIST wrote them down almost that plainly: what exactly is the agent, who delegated authority to it, what is it allowed to do, and how are its actions logged and constrained. The governance frameworks that decide which enterprises win with agents all assume those four answers exist. Almost nobody has them.

In February 2026 NIST's Center for AI Standards and Innovation announced the AI Agent Standards Initiative, with agent security and identity as one of three named workstreams. Alongside it the National Cybersecurity Center of Excellence published a draft concept paper, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," and closed public comment on 2 April 2026. It does not invent a protocol. It stretches the ones already in the building: OAuth 2.1, OpenID Connect, SPIFFE and SPIRE for workload attestation, SCIM for lifecycle, NGAC for attribute-based access, and the Model Context Protocol for tool access. And it is blunt about the part vendors skip, asking how to bind agent identity to human identity for on-behalf-of scenarios, and demanding that agents log their actions and intent in a tamper-proof and verifiable manner. Meanwhile the credential surface underneath all of this keeps expanding, and the certificate rules governing it keep tightening on a schedule that has nothing to do with AI and no interest in waiting for it, which is the same structural pressure driving the post-quantum migration deadlines already running against your encrypted traffic.

The certificate number is the one that should worry an operations lead, because it is the only figure on that grid that is a hard deadline rather than a trend. The ceiling drops again in March 2027 and lands under seven weeks in March 2029, and at that point the window for reusing domain validation data shrinks to ten days. Manual renewal stops being slow and starts being impossible. Any agent that terminates or initiates TLS on your behalf inherits that clock, and if you cannot enumerate which agents hold which credentials, you cannot rotate them on the schedule the rules now require.

What identity for an agent actually means

Strip away the protocol names and agent identity decomposes into six practical obligations. None of them is exotic. All of them are things your existing IAM stack does for humans and mostly fails to do for software that makes choices. The table below is the working checklist, and it is deliberately written as what you have to be able to prove, not what you have to buy.

Read down the Insight column and the pattern is uncomfortable. Five of the six obligations are things you can implement today with protocols that shipped years ago. Only the audit row really needs new work, because logging an agent's intent, meaning why it chose the action, is not something any existing standard captures well. That is where the standards effort will actually spend its time, and it is also the row your regulator will ask about first.

Where this breaks in practice

The first breakage is organisational, not technical. Identity lives with the security team, agents live with the platform or data team, and the person who actually authorized the agent to touch a customer record is a product manager who has never seen an IAM console. Palo Alto Networks' 2026 identity security survey of more than 2,900 security decision-makers found that disconnected identity systems add roughly 12 hours to the average identity-related incident. That gap is not spent fixing anything. It is spent asking who owns this thing.

The second breakage is that agents multiply credentials as a side effect of being useful. Every tool an agent connects to wants a key. Every connector config file becomes a place a key can sit. This is the same failure pattern that made verified caller identity such a fight in telecom, where operators had to be pushed into displaying the KYC name behind a number before anyone could trust who was calling. The lesson transferred badly. We are once again shipping systems that act on our behalf without a verified name attached.

And here is the part I am not sure about, which is worth saying out loud rather than hiding behind a framework. Should an agent hold a first-class identity of its own, or should it only ever borrow a human's? Giving it its own identity makes revocation clean and audit trails honest, but it also creates a permanent non-human principal that outlives the reason it existed. Borrowing keeps accountability tight and makes the agent disappear when the human leaves, but it collapses the moment an agent runs unattended for a week. I lean toward first-class identity with a mandatory delegation link, but I would not call that settled, and anyone selling you certainty on this in 2026 is selling.

Watch-outs before you buy anything:

• Any vendor claiming NIST compliance for agent identity is claiming compliance with a concept paper. There is no standard to comply with yet.
• Inventory before policy. If you cannot list every agent and the credentials it holds, a policy engine just enforces rules against the half you know about.
• Logging the action without logging the delegation is worthless. "Agent X deleted the record" is not an audit trail. "Agent X, acting for Priya, deleted the record under ticket 4471" is.
• Treat agent credentials as in-scope for your certificate automation programme now, not after the next validity cut lands.

Pick your three highest-privilege agents this week, and for each one write down the human who authorized it, the exact scope it holds, and where its actions are logged. If you cannot complete that sentence for all three, you do not have an agent identity problem to plan for later. You have one now, and it is already in production.