Do I need a cookie banner if I only use "essential" cookies?

The honest answer to “can I skip the banner?” is “yes, if you only use cookies that are strictly necessary for what the user asked for.” The unhonest version, sold by some consent-management vendors, treats the exception as a marketing claim. The real list of strictly-necessary cookies is short, and most SMB sites set at least one cookie that breaks the exemption.

What qualifies as strictly necessary

ePrivacy 5(3) exempts storage that is “strictly necessary for the provision of an information society service explicitly requested by the subscriber or user.” The interpretation people usually reach for here, the EDPB’s Guidelines 02/2023, is the wrong instrument: those guidelines address the scope of Article 5(3), what counts as storage or access in the first place, and deliberately do not interpret the strictly-necessary exemption. The working list still traces to WP29 Opinion 04/2012 (WP194), which goes through the cookie types that qualify. It is short:

• Session cookies for authentication. When a user is logged in, maintaining the session is necessary to deliver the requested service.
• CSRF protection tokens. Anti-forgery tokens on form submissions.
• Load balancer routing. Sticky-session cookies that ensure the user’s requests reach the same backend during a session.
• Shopping cart state. A cart cookie persisting cart contents between page loads on a checkout flow the user initiated.
• Security cookies that detect attacks on a service the user requested. Cloudflare’s bot management cookie, Akamai’s session-based fraud-detection cookies in narrow contexts.
• Explicit user-preference cookies. A user clicks “dark mode,” the site sets a preference cookie to remember it next visit. The storage is necessary because the user explicitly asked for the customization.

What does not qualify

• Analytics, even “privacy-friendly” ones. GA4, Matomo, Plausible, Fathom, Mixpanel, Amplitude. Helpful to you, not necessary for the user.
• Performance cookies that A/B test or personalize. Even if the personalization is intended to benefit the user, the storage exceeds “strictly necessary”, the user can be served the page without it.
• Default theme or default language cookies set without user action. Setting a language preference based on the user’s Accept-Language header is functionality; persisting that choice as a cookie before the user has interacted is storage that exceeds necessity.
• Security cookies where there is nothing much to secure. This is a matter of degree, not a clean line, and the exempt list above is the general case: bot management protecting a service the user is actively using is normally fine. The harder case is the same cookie applied blanket-wide to purely static marketing pages with no form, no login and no transaction. Some authorities would still accept it as protecting the site’s availability; the conservative reading is that the necessity argument weakens as the thing being protected disappears. If you rely on it, be able to name the attack it prevents on that page.
• Identifiers whose purpose is to follow the user across sites. Third-party advertising and analytics identifiers, and any first-party cookie set so that another party can read it. Note the distinction carefully, because a domain attribute on its own proves nothing: a sticky-session or single-sign-on cookie set at .example.com so your own subdomains can read it is still strictly necessary, exactly as the exempt list above says. What breaks the exemption is the cross-site purpose, not the presence of a leading dot.
• Anything from a third-party ad, social, or analytics vendor. The EDPB has explicitly rejected the “legitimate interest” argument for tracking storage. Strictly necessary excludes anything serving a third party.

The narrow path that actually works

A site that legitimately runs banner-free is uncommon but exists. Typical patterns:

• Pure logged-in SaaS dashboards. A signed-in user’s authenticated session and CSRF protection only. No analytics on the dashboard, or analytics on a separate marketing site that does run a banner.
• Static informational sites. A small business homepage with no forms, no analytics, no third-party widgets, hosted on Cloudflare with bot management disabled on the static pages. Possible but increasingly rare.
• Analytics that writes nothing to the device. Vercel Web Analytics, Plausible in its cookieless mode, Cabin. Where a tool genuinely stores nothing on and reads nothing from terminal equipment, Article 5(3) is not engaged at all, though the GDPR still governs whatever data results. The condition is that nothing else on the site writes either. In France there is a second route to the same outcome, CNIL’s audience-measurement exemption, which can cover correctly configured tools that do use storage. Everywhere else, treat a vendor’s cookieless claim as something to confirm in DevTools rather than accept from a marketing page.

The audit question

Before claiming the essential-only exemption, run a fresh cookie inventory. Open DevTools, load your site fresh, check the Application tab for every cookie set on first load, every localStorage entry, every IndexedDB key. Cross-reference each against the strictly-necessary list above. If even one entry on your site falls outside the list, you are subject to ePrivacy 5(3) consent.

A free Veracly scan covers one page, and on that single page we routinely turn up storage on sites that describe themselves as “essential only.” The usual culprits: a third-party widget (Calendly, a chat box), an embed (YouTube, Vimeo), a CDN cookie applied more broadly than anyone intended. Note what one page implies, though: the analytics script somebody left on a subpage after an experiment is precisely the thing a one-page scan will not see. That is an argument for walking the rest of the site yourself, not for assuming the rest is clean.

Veracly’s position

Veracly does not enforce a banner where none is required, and it does not assume an essential-only exemption without evidence either. What a scan returns is the cookies and storage keys observed on the pages it visited, before any consent gesture, with the entries that look non-essential called out against Article 5(3). Four things to hold it to:

• It is an observation, not an inventory. One page on a free scan, up to your plan’s page cap otherwise, and only what actually loaded during that visit. Storage is recorded as key and database names, never values.
• Third-party requests only. Anything served from your own hostname, including self-hosted Matomo or a server-side tag endpoint on your own subdomain, is invisible to the scan by design.
• The strictly-necessary classification is a name-pattern heuristic, not a vendor database. It recognises the common session, CSRF and CDN cookie shapes. A genuinely essential cookie with an unusual name can be flagged, and a tracker with an innocuous name can slip past. Read the output as a shortlist to check, not a verdict to file.
• Free scans show samples, not the full set. Three cookie samples, three request URLs, three rendered priorities — and those three do carry a written explanation, as does the executive summary. What a free scan has none of is the copy-paste remediation and the evidence screenshots.

The site operator decides whether to remove the offending storage or to add a banner. We would rather hand you a short, honest list you can verify in DevTools than a confident one you cannot.

See also: GDPR vs ePrivacy: which one governs cookies? · Cookies, localStorage, IndexedDB: which require consent?