Germany’s Device-Access Rule Is Broader Than Website Cookies
Germany’s rule on storing or reading information from a user’s device is usually described as a cookie rule. Its language reaches much further: apps, connected products, pixels, local storage and device fingerprinting can all enter the analysis.
Germany’s Telecommunications and Telemedia Data Protection Act entered into force on 1 December 2021 as the TTDSG. It was renamed the Telecommunications Digital Services Data Protection Act, or TDDDG, in 2024 to reflect changes in digital-services terminology. The central device rule remains section 25.
Section 25 generally requires consent before information is stored in a user’s terminal equipment or information already stored there is accessed. It contains two exceptions: operations used solely to transmit a communication over a public telecommunications network, and operations strictly necessary to provide a digital service expressly requested by the user.
The protected object is the device
The rule does not depend on whether the information is personal data. That distinguishes the first question under section 25 from the later GDPR analysis. Reading an identifier from a device can require consent even if the provider argues that the value cannot identify a named person. If the resulting processing concerns personal data, the organisation must then also establish a GDPR legal basis and meet the other GDPR duties.
The concept of terminal equipment is broad. It includes phones and laptops, but the statutory definition and German supervisory guidance also reach connected devices such as smart-home equipment. A product team should therefore look for storage and access operations wherever software interacts with a user’s connected equipment—not only in the browser’s cookie list.
Examples can include software development kits in mobile apps, tracking pixels, local-storage objects, advertising identifiers, device fingerprinting, connected-TV measurements and telemetry written to or retrieved from an IoT product.
“Useful” is not “strictly necessary”
The most contested exception is the one for an operation strictly necessary to provide a service expressly requested by the user. Necessity is assessed against the service the person actually requested, not every feature the provider would like to operate.
A shopping-basket identifier may be necessary for an online shop to remember selected products during a session. A security token may be necessary to maintain an authenticated session. Cross-site advertising measurement is not made necessary simply because advertising funds the service. Convenience, analytics and commercial benefit do not automatically satisfy the test.
Teams should document the requested service, the technical operation, why that operation is indispensable and whether a less intrusive design could provide the same function. Labels such as “functional” or “essential” are not analysis.
Consent design needs technical enforcement
When consent is required, it must meet GDPR standards: informed, specific, freely given and expressed through an affirmative action. The interface must also control the underlying technology. A compliant-looking banner is irrelevant if tags fire before the user chooses, if withdrawal does not stop subsequent access or if rejected technologies return through another domain.
The consent record should identify the user or device where appropriate, the choice, time, purposes, vendors and notice version. It should not itself create an unnecessary tracking mechanism. Withdrawal should be as easy as giving consent, and the preference should propagate to applications, tag managers and downstream recipients.
Build an endpoint-access inventory
A cookie scan is a useful discovery tool, but it is not a complete inventory. Organisations should ask product and engineering teams to record:
- what information is written to or read from a user’s equipment;
- the component and third party responsible;
- the purpose and lifetime of the operation;
- whether the transmission or strict-necessity exception is claimed;
- the separate GDPR basis if personal data is processed; and
- the technical signal that prevents operation after refusal or withdrawal.
Mobile releases and embedded-device firmware should be included in change management. A new analytics SDK can alter the legal position even when the privacy policy’s high-level purposes remain unchanged.
One operation, two legal layers
The cleanest compliance record separates the layers. First ask whether information is stored in or accessed from terminal equipment and whether section 25 permits it. Then ask what personal-data processing follows under the GDPR. Combining both questions into a generic “legitimate interests” statement can miss the consent requirement at the device layer.
Germany’s provision is a reminder that privacy engineering begins at the interface between code and equipment. The correct unit of review is not the banner; it is each read and write operation, the service it supports and the control that actually governs it.
Official sources
- Federal Ministry of Justice: TDDDG, including section 25
- German data-protection authorities: guidance for telemedia providers
Continue the series
- Next in Germany: Germany’s Supply-Chain Law Turns Complaints Into Risk Intelligence
- European National Cyber & Digital Law Series index
This article provides general information and is not legal advice.
