Zoho Analytics EU Allowlist: Add Four Ranges, Then Test

Zoho has moved the action deadline for new Zoho Analytics source IP ranges used for connections to cloud databases in its EU data center from July 24 to August 8, 2026.

The notice is narrow. It applies to organizations using analytics.zoho.eu to reach cloud databases through Live Connect or import connections. FTP and FTPS sources are affected only when the server is configured to accept connections from allowlisted IP addresses.

An IP allowlist is the network rule that decides which source addresses may reach a database or file server. Zoho says the four new ranges must be added alongside the existing entries. It also warns that affected connections can be interrupted and scheduled imports can fail if the ranges are not allowed.

The extra time is useful. It does not make this a paperwork-only network change.

An allowlist change is finished only when the data is fresh, reconciled, and trusted by the people using it.

What changed—and why the dates matter

The four new ranges are:

• 185.230.213.98/31
• 185.230.213.100/32
• 185.230.215.98/31
• 185.230.215.100/32

Add them. Do not replace or remove the ranges already on your allowlist.

Zoho's announcement now says the deadline has been extended to August 8. Its separate IP reference page still labels the new ranges as effective from July 24. Those statements are not proof that traffic from the new ranges was held back.

For an affected connection, the practical response is to add the ranges now and test. Recheck the official IP page during change approval so the implementation uses Zoho's current list rather than a copied list in an old ticket or third-party article.

Does this affect your team?

Answer these questions in order:

1. Does your Zoho Analytics URL use analytics.zoho.eu?
2. Does that account connect to a cloud database through Live Connect or an import connection?
3. Do any FTP or FTPS sources accept traffic only from named IP addresses?

If the answer to the first question is no, this EU notice is not your change instruction. Use Zoho's data-center-specific reference instead.

If the first answer is yes but there are no affected database or restricted FTP/FTPS connections, record that finding and stop. Do not broaden network access just because a vendor published new ranges.

The AorBorC view: allowlisting is a data-freshness release

A connection test is necessary, but it is not enough. An import-backed dashboard can still render the last successfully loaded dataset after a scheduled import fails; Live Connect failures can surface differently. A page load proves the page works; it does not prove that the order, inventory, finance, service, or operational data behind it is current.

That matters when Shopify, Odoo or other ERP modules, Zoho CRM and Books, or custom operational data reaches Zoho Analytics through an affected cloud-database or restricted FTP/FTPS path. The notice does not establish that native application connectors are affected. Stale figures can travel into scheduled emails, exported reports, management reviews, approvals, or integrations.

Treat the change like a small release with three owners:

• A network or security owner who changes the rule.
• A data-connection owner who tests Live Connect, imports, and restricted file sources.
• A report owner who confirms that decision-critical outputs are fresh and correct.

One named person should hold the final sign-off.

Kept current, the connection register can also support later IP changes, credential rotations, and refresh investigations because the affected paths and owners are already known.

Implementation checklist

1. Inventory the affected paths. Record the Analytics workspace, connection name, source host, connection mode, refresh schedule, network owner, data owner, and downstream reports or exports.
2. Capture a baseline. Save the last successful refresh time, run one representative source query, and record a row count plus one or two business totals that matter to the report.
3. Approve an add-only network change. Add all four new CIDRs exactly as published, preserve the existing allowlist entries, and scope the rule to the intended destination endpoint or service under the network owner's normal controls. Record the rule or change-ticket identifiers.
4. Test each connection type you actually use. Run a known Live Connect query, a manual import, and a restricted FTP/FTPS import where applicable.
5. Observe the next scheduled run. A manual success does not prove the scheduled credential, timing, or job path is healthy.
6. Reconcile the data. Use one shared cutoff or reporting window, identical filters, and an agreed acceptable variance to compare source and Analytics refresh timestamps, row counts, and business totals. For order, stock, or finance reporting, include at least one value an operational leader would use to make a decision. Document the reason for every mismatch outside the accepted variance.
7. Check the downstream chain. Open the critical dashboard, scheduled email, export, or integration that consumes the dataset. Confirm that failure alerts have a named recipient.
8. Retain evidence and monitor. Store the approved ranges, test results, reconciliation evidence, owners, and sign-off. Watch at least one normal reporting cycle after the change.

Risks and limits

• This is not a general outage notice for every Zoho Analytics account.
• The announcement does not say the new ranges were inactive until August 8. Do not treat the extension as evidence that implementation can safely wait.
• Successful connectivity does not prove the imported or queried data is complete.
• Allowlisting does not fix expired credentials, incorrect ports, schema changes, query failures, or unrelated refresh problems.
• Security teams should add only the official ranges needed for the affected connection and should follow their normal review process.
• Verify the current official list before implementing. Public articles should not become permanent firewall source material.

Business takeaway

August 8 is the allowlisting deadline, not evidence of a maintenance window or delayed activation. The deliverable is an add-only allowlist change plus evidence that every decision-critical report is fresh.

Your next move

If nobody can name the affected connections and their report owners, start with the connection register before the firewall rule. Plan the project with the source systems, refresh schedules, critical reports, and any current failure evidence.