Electronics Guide

Articles in This Category

Personal Data in Electronic Systems

Engineers often underestimate how much of what a device handles counts as personal data. Under the GDPR, personal data is any information relating to an identified or identifiable natural person, and identifiability includes indirect routes. A hardware serial number, a MAC address, an advertising identifier, a GPS fix, or a pattern of sensor readings tied to one household can all qualify, even when no name is stored anywhere in the system. Diagnostic telemetry and crash logs frequently sweep up such identifiers by accident, and debug channels left enabled in production are a common source of unintended collection.

Some categories carry heightened obligations. GDPR Article 9 treats health data, along with biometric data processed for the purpose of uniquely identifying a person, as a special category that requires an additional legal condition beyond an ordinary lawful basis. That distinction matters in practice: a fingerprint image used to unlock a phone locally is handled very differently, in both law and architecture, from a facial template uploaded to a server to match against a population database. Location data and information about children attract similar heightened treatment across most modern regimes.

Pseudonymization and anonymization are also distinct, and the difference has architectural consequences. Pseudonymized data, in which identifiers are replaced by tokens while a re-identification key still exists, remains personal data and stays within the scope of the regulation. Genuinely anonymized data, from which no individual can be re-identified by any reasonably likely means, falls outside it. Because robust anonymization is difficult, particularly for high-dimensional sensor data, engineers should treat a claim of anonymity as a design assertion that must be justified rather than a label applied at the end of a pipeline.

Privacy by Design in Electronic Products

Privacy by design treats data protection as an architectural requirement rather than a feature added late in development. The principle, codified in GDPR Article 25 as "data protection by design and by default," asks engineers to embed safeguards into a product from the outset and to make the most privacy-protective settings the defaults. In practice this means collecting only the data a function genuinely needs, processing it locally where possible, and limiting how long it is retained.

Defaults deserve particular attention because they determine what the overwhelming majority of users actually experience. A microphone that streams continuously unless the owner opts out, a companion application that requests location access it does not need, or analytics that ship enabled behave very differently from the same features shipped off by default. Regulators have repeatedly treated permissive defaults as the substance of a violation rather than a minor configuration choice.

Building these controls in early is also pragmatic. The GDPR and the LGPD expect demonstrable safeguards and, for higher-risk processing, a documented data protection impact assessment under GDPR Article 35. Retrofitting privacy into a finished product is costly and often incomplete, whereas decisions made during architecture, such as where data is stored, whether a sensor pipeline ever leaves the device, and how keys are provisioned in the factory, are far cheaper to get right at the design stage. Silicon and enclosure choices in particular are effectively frozen long before software is finished.

Technical Controls Across the Data Lifecycle

Several technical controls recur across privacy-respecting designs, and they map naturally onto the stages of the data lifecycle.

Collection. Sample only what the function requires, and prefer derived features to raw captures. A gesture sensor that reports a classified event rather than a video frame, or a voice interface that computes an on-device wake-word decision rather than streaming continuous audio, reduces exposure at the point where it is cheapest to reduce. Physical indicators, such as an LED wired to the camera power rail, give users evidence that cannot be forged by compromised firmware.

Storage. Encrypt data at rest with a vetted algorithm such as AES, and store the keys in hardware that resists extraction, such as a secure element, a trusted platform module, or a trusted execution environment. Keys derived from a device-unique secret and bound to a user credential prevent a stolen flash chip from yielding readable data. Biometric systems go further and store protected templates rather than raw samples, so that a compromised database does not expose a trait the user cannot change.

Transmission. Protect data in transit with current TLS versions and validated certificate chains, and avoid the common embedded shortcuts of disabled certificate verification, hardcoded credentials, and plaintext local-network protocols. Constrained radio links need equivalent care at the link layer, since a device that terminates TLS only at a gateway leaves the last hop unprotected.

Access and retention. Restrict who and what can read sensitive records through authentication and least-privilege access control, and log access in a way that supports later investigation. Define retention periods per data type and enforce them automatically, because retention rules that depend on manual cleanup rarely survive contact with production. Deletion must reach backups, analytics stores, and processor systems, not only the primary database, and it must be verifiable when a user exercises a deletion right.

Where personal data must leave the device, pseudonymization, aggregation, and template protection limit what an attacker or unintended recipient can learn. Techniques such as on-device aggregation before upload can preserve analytical value while discarding the individual records that create the risk.

The Global Regulatory Landscape

No single law governs data privacy worldwide, so products sold internationally must satisfy a patchwork of overlapping regimes. The GDPR, which has applied since May 25, 2018, is the most influential model and has shaped comprehensive laws elsewhere, including Brazil's LGPD and, with notable differences, China's Personal Information Protection Law (PIPL). Other established frameworks include Canada's PIPEDA and Japan's APPI. The GDPR's enforcement ceiling, up to 20 million euros or 4 percent of total worldwide annual turnover for the most serious infringements, whichever is higher, explains much of its influence on corporate behavior.

In the United States the picture is sector-specific and fragmented. There is no single federal privacy statute, but roughly twenty states now have comprehensive consumer privacy laws in effect, and the count continues to grow as further statutes reach their effective dates. Sector rules such as HIPAA for health information and the Gramm-Leach-Bliley Act for financial data apply on top of these, and technology-specific statutes add another layer: Illinois's BIPA imposes consent and retention requirements on biometric identifiers and supports private lawsuits, which has made it the most consequential single privacy statute for many device makers.

Children's privacy has tightened as well. The Federal Trade Commission's amendments to the COPPA Rule, the first substantial revision since 2013, took effect on June 23, 2025, with full compliance required by April 22, 2026. The amendments add biometric identifiers to the definition of personal information, require separate verifiable parental consent for disclosures that are not integral to the service, and oblige operators to maintain a written information security program and a written data retention policy. Connected toys, educational hardware, and any device plausibly directed at children fall within this scope.

For device makers, the practical consequence is that lawful basis, transparency, individual rights, breach notification, and constraints on cross-border transfers all vary by market. Breach timelines are unforgiving: the GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, which means incident response, forensic logging, and contact paths must be arranged before an incident rather than during one. Many manufacturers manage the complexity by designing to the strictest applicable standard, so that one privacy-respecting architecture can be deployed globally rather than maintaining a separate variant for each jurisdiction.

Where Privacy Law Meets Product Compliance

Privacy obligations increasingly arrive through the same conformity assessment channels that hardware teams already navigate for safety and electromagnetic compatibility. In the European Union, Commission Delegated Regulation (EU) 2022/30 activated the cybersecurity requirements of the Radio Equipment Directive, applicable since August 1, 2025. One of those requirements, Article 3(3)(e), addresses the protection of personal data and privacy directly, and the harmonized standard EN 18031-2 covers radio equipment that processes personal, traffic, or location data. Privacy is therefore now a CE marking question for a large share of connected products, not solely a matter for legal and compliance staff.

The EU Cyber Resilience Act extends this pattern to products with digital elements more broadly. Its vulnerability and incident reporting obligations apply from September 11, 2026, requiring manufacturers to notify the relevant national computer security incident response team and ENISA of actively exploited vulnerabilities and severe incidents within 24 hours, with a substantive update within 72 hours. The remaining obligations, including the essential cybersecurity requirements, conformity assessment, and technical documentation, apply from December 11, 2027. Because a breach of confidentiality is frequently the harm that a security defect produces, security compliance and privacy compliance now share evidence, timelines, and engineering effort.

Systems that recognize or categorize people attract an additional layer. The EU Artificial Intelligence Act prohibits certain practices outright, including most real-time remote biometric identification in publicly accessible spaces for law enforcement purposes, and those prohibitions have applied since February 2, 2025. Teams building cameras, access control systems, or emotion and biometric categorization features should establish early whether their product falls into a prohibited or a regulated class, because the answer can constrain the feature set rather than merely add paperwork.

Standards and Frameworks for Engineering Teams

Regulations state outcomes; standards supply the vocabulary and the process for achieving them. ISO/IEC 29100 defines a privacy framework and a common terminology, including the privacy principles that most later work builds on. ISO/IEC 27701 specifies a privacy information management system and, in its 2025 revision, became a standalone certifiable management system standard rather than an extension that required an existing ISO/IEC 27001 information security management system. For biometric systems, ISO/IEC 24745 addresses biometric information protection, including template protection, irreversibility, unlinkability, and renewability.

In the United States, the NIST Privacy Framework offers a voluntary, risk-based structure that pairs with the NIST Cybersecurity Framework and translates well into engineering practice, since it organizes work around identifying data flows, governing them, and controlling them rather than around any single jurisdiction's text. A version 1.1 update, aligning the framework with Cybersecurity Framework 2.0 and addressing privacy risks arising from artificial intelligence, has been issued for public comment. NIST's privacy engineering work also supplies the useful objectives of predictability, manageability, and disassociability, which give designers concrete properties to argue about at review time.

None of these frameworks certifies a product as lawful. Their value is that they turn diffuse legal duties into repeatable artifacts, such as data inventories, processing records, impact assessments, and control mappings, that a team can produce, review, and hand to an auditor or a regulator when asked.

About This Category

Data privacy and information protection represent an increasingly important domain within electronics safety and standards. As devices grow more capable of collecting data, the potential for privacy harm grows with them, and regulators worldwide are responding with more demanding requirements that now reach into product conformity assessment itself. The articles in this category help electronics professionals understand their obligations and implement appropriate protections in the products they design and manufacture, treating privacy not as a compliance afterthought but as a core element of responsible engineering.