Sunday, September 27, 2026

CRA Reporting Gives Vendors 24 Hours

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.

Laptop security alert beside a 24-hour stopwatch, illustrating CRA reporting deadlines for vendors

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

Key Takeaways

A 24-hour exploited-flaw warning should be a legal duty for every software vendor, not a perk reserved for EU buyers.

  • The EU gives vendors 24 hours to warn and 72 to notify once they know of an exploit.
  • Warnings go to a national CSIRT through ENISA's platform, not to the public.
  • US law puts reporting on the breached operator, not the vendor whose product failed.
  • Outside the EU, write a 24-hour exploited-flaw notice into every contract you renew.

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.

Early Warning Window

24 hours

One unstaffed weekend breaches it

Flat Fine Ceiling

EUR 15 million

Enough to sink a small vendor

Filings Per Exploited Flaw

3

A paper trail buyers can cite

Turnover-Based Fine

2.5%

Whichever is higher applies

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.

"

In Europe, sitting on an exploited flaw over one weekend risks a fine priced against a vendor's entire global turnover. In America, the same silence costs nothing.

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.

Dimension EU vs US What it means for you
💰 Who reports EU The product vendor
US The breached operator
⚠️ A supplier's flaw becomes your filing
⚖️ Legal force EU Binding since Sept 2026
US Pledge, signed by choice
❌ Only your contract makes it enforceable
⏱ First alert EU 24 hours, to a CSIRT
US 72 hours, operators only
✅ EU buyers hear two days sooner
⏱ Final report EU 14 days after a fix
US No vendor duty
✅ A patch date you can hold them to
🌍 Users told EU Impacted users, by law
US No such right
⚠️ Same product, warned only in Europe
🔒 Who sees it EU A CSIRT, not the public
US Nobody, by rule
✅ The warning gives attackers nothing
🛠 Old products EU Past end of support
US No duty at all
❌ Legacy kit goes quiet outside the EU
🏁 Best suited for EU Any buyer inside the EU
US Buyers who contract for 24h
🏁 Elsewhere, the clause is your only clock

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.

Oct 2025. May 2026. 11 Sep 2026. 11 Dec 2027. US rule first due. US rule new target. EU vendor clock live. Open source joins. 15 months.

If you sell to EU customers, your reporting clock is already running, while the US incident rule has already missed its first deadline. Dates from the European Commission and Ballard Spahr's Byte Back; the final gap is our own count.

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.

Check these before your next renewal

Your contract sets an exploited-flaw notice of one day or less.

Your vendor names who files on a Sunday.

The product is also sold in Europe, so the warning exists.

Unsupported products still carry a written warning promise.

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.

Saturday, September 5, 2026

The DPDP Consent Manager Deadline Trap

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.

Timeline graphic marking the DPDP consent manager deadline against India's phased DPDP rule commencement
TL;DR: Rule 4 of the DPDP Rules, 2025 commences on 13 November 2026 and switches on India's consent manager framework. The Data Protection Board that must register those managers is not yet fully constituted. Build interoperable consent handling now, and plan for a registry that arrives late.

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.

Phase-in runway

18 months

Notification to full force

Entry bar

Rs 2 crore

Minimum registered net worth

Managers registered

0

As of September 2026

Rules in force

1 of 3

Commencement phases live today

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.

"

A framework with a hard start date and not one registered intermediary behind it is not a grace period. It is a deadline you will meet alone, inside your own stack.

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.

Category Detail Insight
Phase 1 Board and institutional rules live since 13 Nov 2025 Sets up the regulator, imposes no duties
Phase 2 Rule 4 and First Schedule from 13 Nov 2026 Registration opens, interoperability becomes real
Phase 3 Rules 3, 5 to 16, 22 and 23 from 13 May 2027 Notice, breach and erasure duties start biting
Eligibility Indian incorporation plus the two crore net worth floor Excludes foreign-domiciled consent vendors outright
Retention Consent records held for a minimum of seven years Outlives typical CRM and log retention windows
Data blindness Routed personal data must stay unreadable to the manager Forces token or pointer based integration design
Regulator Board not fully constituted, MeitY applications open in 2026 No registry means no counterparty to test against
Build window Under 10 weeks from September 2026 to Rule 4 Design freeze needed by mid-October to land it

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.

13 Nov 2025. 13 Nov 2026. 13 May 2027. Rules notified. Fiduciary duties. Consent managers. Board framework only. Rule 4 commences. Notice and erasure.

The three commencement points set out in the Digital Personal Data Protection Rules, 2025 as notified by MeitY, running from the institutional framework in November 2025 through to the duties on data fiduciaries in May 2027.

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.

Key takeaways: the four capabilities Rule 4 assumes you already have

1. Purpose-bound records. Every consent stored as a machine-readable object carrying the purpose it was given for, not a boolean flag on a user row.

2. External ingestion. An authenticated endpoint that accepts grants and withdrawals originating outside your product and treats them as binding instructions.

3. Downstream propagation. A fan-out path that carries a withdrawal to every copy of the data, including the ones your analytics team forgot to document.

4. Auditable history. An append-only log that can reconstruct the consent state of any individual on any past date, and hold it for seven years.

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.

Friday, September 4, 2026

MCP Security Is Where Your AI Agent Defenses Actually Break

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.

MCP Security Is Where Your AI Agent Defenses Actually Break
TL;DR: Enterprises spent 2026 arguing about agent identity. The real exposure sits one layer down, in the Model Context Protocol servers that give agents hands. The NSA published an MCP security advisory in May 2026, and the July spec rewrite fixed some flaws while adding new ones.

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.

Deprecation window

12 months

for legacy MCP versions

Exposed instances

200,000

flagged across the supply chain

Breach cost

$4.99M

IBM 2026 global average

SDKs affected

4 of 4

Python, TypeScript, Java, Rust

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.

"

Every official SDK carried the same design flaw. That is not a bad implementation. That is a bad assumption, shipped in four languages at once.

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.

Category Detail Insight
Advisory NSA Cybersecurity Information Sheet, Ver. 1.0, May 2026 Names code execution and missing RBAC
Spec Release 2026-07-28, stateless via six SEPs Session hijacking removed at protocol layer
CVEs 7 high or critical CVEs confirmed as of May 2026 Systemic design, not isolated coding bugs
Supply chain postmark-mcp backdoor reached 300 organisations, September 2025 One package silently copied outgoing mail
Disclosure 30+ disclosures filed April 2026; policy file updated 9 days later Response lag measured in days
Blast radius 150 million MCP package downloads by mid-2025 Reach scales faster than review capacity
New risk MCP-Method and MCP-Name headers can carry keys or PII Header mapping leaks secrets to intermediaries
First move Any server answering without auth: treat as compromised today Assume access, then prove otherwise

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.

Apr 2025 May 2025 Nov 2025 Nov 2025 Asana cross-org leak feature pulled offline GitHub MCP injection private data in a PR WhatsApp exfiltration poisoned tool descriptions Anthropic Git MCP path bypass chained to RCE

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.

Key Takeaways: the controls the NSA advisory actually names

  • Validate every parameter against defined schemas and the expected value ranges.
  • Isolate each tool's execution using AppContainers, seccomp, AppArmor or SELinux.
  • Extend MCP with cryptographic signatures inside the JSON payload, time bound.
  • Log every invocation with exact parameters, the identities involved, and cryptographic hashes of results.
  • Scan the network for unauthenticated MCP servers instead of trusting the asset list.

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

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