15 Privacy and User Consent in IoT

In 60 Seconds

IoT privacy consent must be explicit, informed, granular, and as easy to withdraw as it was to grant. GDPR requires freely given consent that is not bundled with service access, and IoT devices face unique challenges because they collect data continuously, often without screens for consent dialogs. Apply data minimization (collect only what is needed), edge processing (process locally before transmitting), and Privacy by Design principles (embed privacy into architecture from the start, not as an afterthought).

15.2 GDPR and Privacy Regulations for IoT

The General Data Protection Regulation (GDPR) establishes strict requirements for processing personal data. IoT systems face unique challenges because they collect data continuously from sensors, often without traditional user interfaces.

15.2.1 GDPR Principles Applied to IoT

GDPR Principle	Article	IoT Application	Example
Lawfulness	Art. 6	Must have legal basis for collection	Smart meter needs consent for detailed usage patterns
Purpose Limitation	Art. 5(1)(b)	Collect only for specified purposes	Thermostat data cannot be used for advertising
Data Minimization	Art. 5(1)(c)	Collect only what’s necessary	Fitness tracker shouldn’t collect location for step counting
Accuracy	Art. 5(1)(d)	Keep data correct and updated	Medical IoT must maintain accurate readings
Storage Limitation	Art. 5(1)(e)	Don’t keep data longer than needed	Security camera footage deleted after 30 days
Integrity & Confidentiality	Art. 5(1)(f)	Protect against unauthorized access	Encryption for smart lock access logs

15.3 Consent Mechanisms for IoT

Designing consent mechanisms for IoT is challenging because traditional web consent patterns (cookie banners, checkboxes) don’t work for screenless devices or continuous data collection.

15.3.1 Consent Requirements Under GDPR

For consent to be valid under GDPR Article 7, it must be:

Requirement	Definition	IoT Challenge
Freely Given	Not tied to service access	Devices often require data for core function
Specific	For defined purposes	Sensors collect multipurpose data
Informed	User understands what they’re consenting to	Complex data flows hard to explain
Unambiguous	Clear affirmative action	No screen for buttons/checkboxes
Withdrawable	As easy to withdraw as to grant	How do you “un-consent” to a smart speaker?

15.3.3 Designing Granular Consent

Instead of all-or-nothing consent, IoT systems should offer granular choices:

Feature Category	Core Function	Optional Enhancement	Third-Party Sharing
Smart Thermostat	Temperature control (required)	Energy optimization tips	Utility company data sharing
Fitness Tracker	Step counting (required)	Social leaderboards	Research data contribution
Smart Speaker	Voice commands (required)	Personalized recommendations	Skills marketplace analytics

15.4 Data Minimization Principles

Data minimization is a core Privacy by Design principle requiring IoT systems to collect only the data necessary for their specified purpose.

15.4.1 The Data Minimization Hierarchy

Diagram of the data minimization principle applied to IoT, showing a comparison of collected data fields such as full name, email, GPS location, device ID, contact list, and sensor data, with indicators marking which fields are strictly necessary for the stated purpose and which should be eliminated to reduce privacy risk — Figure 15.3: Data minimization framework showing which data fields are necessary versus excessive, with a filtering process that retains only essential identifiers and sensor readings

15.4.2 Practical Data Minimization Examples

IoT Device	Over-Collection	Minimized Collection	Rationale
Smart Thermostat	Minute-by-minute temp + occupancy + location	Hourly temperature averages	Hourly sufficient for optimization
Fitness Tracker	GPS coordinates every second	Route summary (start/end, distance)	Full GPS reveals home/work locations
Smart Speaker	All audio recorded and uploaded	Local wake word detection, upload only commands	Most audio is ambient noise
Security Camera	24/7 cloud recording	Local storage, motion-triggered cloud backup	Continuous recording captures unnecessary footage

Putting Numbers to It

Data Minimization via Sampling Rate: Consider a smart thermostat collecting temperature readings. Collecting every minute yields $60 \times 24 = 1,440$ readings/day. Each reading includes timestamp (8 bytes), temperature (4 bytes), occupancy (1 byte), and device ID (16 bytes), totaling $29$ bytes. Daily data volume: $1,440 \times 29 = 41,760$ bytes/day $\approx 41.8$ KB/day. Over a year: $41.8 \times 365 = 15,257$ KB $\approx 15$ MB per device. For 1 million devices, annual storage is $15$ TB, with cellular transmission costs (at $\$0.20$/MB) of $15 \times 10^6 \times 0.20 = \$3,000,000$ annually. However, HVAC optimization algorithms only need hourly granularity for energy efficiency recommendations. Reducing to hourly sampling: $24$ readings/day, $24 \times 29 = 696$ bytes/day $\approx 0.68$ KB/day, annual $248$ KB per device. For 1 million devices: $248$ GB annually (98.3% storage reduction), transmission cost $\$49,600$ (98.3% cost reduction). The key privacy win: minute-by-minute data reveals detailed occupancy patterns (when you wake, leave, return), while hourly averages provide sufficient thermal modeling without surveillance-level inference. This is data minimization in practice: collect at the coarsest granularity sufficient for the stated purpose.

Show code

viewof samplingInterval = Inputs.range([1, 60], {
  value: 1,
  step: 1,
  label: "Sampling interval (minutes)"
})

viewof numDevices = Inputs.range([1000, 5000000], {
  value: 1000000,
  step: 1000,
  label: "Number of devices"
})

viewof costPerMB = Inputs.range([0.01, 1.00], {
  value: 0.20,
  step: 0.01,
  label: "Cellular cost ($/MB)"
})

Show code

{
  const readingsPerDay = Math.floor(1440 / samplingInterval);
  const bytesPerReading = 29;
  const dailyBytesPerDevice = readingsPerDay * bytesPerReading;
  const annualKBPerDevice = (dailyBytesPerDevice * 365) / 1024;
  const annualStorageGB = (annualKBPerDevice * numDevices) / (1024 * 1024);
  const annualStorageTB = annualStorageGB / 1024;
  const annualMB = (annualKBPerDevice * numDevices) / 1024;
  const annualCost = annualMB * costPerMB;

  const baseReadings = 1440;
  const baseDailyBytes = baseReadings * bytesPerReading;
  const baseAnnualKB = (baseDailyBytes * 365) / 1024;
  const baseStorageGB = (baseAnnualKB * numDevices) / (1024 * 1024);
  const baseMB = (baseAnnualKB * numDevices) / 1024;
  const baseCost = baseMB * costPerMB;

  const storageReduction = baseDailyBytes > 0 ? ((1 - dailyBytesPerDevice / baseDailyBytes) * 100).toFixed(1) : 0;
  const costReduction = baseCost > 0 ? ((1 - annualCost / baseCost) * 100).toFixed(1) : 0;

  const formatNum = (n) => {
    if (n >= 1e12) return (n / 1e12).toFixed(1) + "T";
    if (n >= 1e9) return (n / 1e9).toFixed(1) + "B";
    if (n >= 1e6) return (n / 1e6).toFixed(1) + "M";
    if (n >= 1e3) return (n / 1e3).toFixed(1) + "K";
    return n.toFixed(0);
  };

  const formatCost = (n) => {
    if (n >= 1e6) return "$" + (n / 1e6).toFixed(2) + "M";
    if (n >= 1e3) return "$" + (n / 1e3).toFixed(1) + "K";
    return "$" + n.toFixed(2);
  };

  const storageLabel = annualStorageTB >= 1
    ? annualStorageTB.toFixed(1) + " TB"
    : annualStorageGB.toFixed(1) + " GB";

  const privacyLevel = samplingInterval >= 30
    ? { label: "Low Risk", color: "#16A085", desc: "Coarse granularity limits behavioral inference" }
    : samplingInterval >= 10
    ? { label: "Medium Risk", color: "#E67E22", desc: "Some occupancy patterns inferable" }
    : { label: "High Risk", color: "#E74C3C", desc: "Detailed behavioral patterns revealed (wake, leave, return)" };

  return html`<div style="background: var(--bs-body-bg, #fff); border: 2px solid #2C3E50; border-radius: 8px; padding: 20px; font-family: Arial, sans-serif; color: var(--bs-body-color, #333);">
    <h4 style="margin: 0 0 16px 0; color: #2C3E50;">Data Minimization Impact Calculator</h4>
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); gap: 12px; margin-bottom: 16px;">
      <div style="background: var(--bs-light, #f8f9fa); border-radius: 6px; padding: 12px; text-align: center;">
        <div style="font-size: 0.8em; color: #7F8C8D;">Readings/Day</div>
        <div style="font-size: 1.6em; font-weight: bold; color: #2C3E50;">${readingsPerDay}</div>
      </div>
      <div style="background: var(--bs-light, #f8f9fa); border-radius: 6px; padding: 12px; text-align: center;">
        <div style="font-size: 0.8em; color: #7F8C8D;">Annual Storage (all devices)</div>
        <div style="font-size: 1.6em; font-weight: bold; color: #3498DB;">${storageLabel}</div>
      </div>
      <div style="background: var(--bs-light, #f8f9fa); border-radius: 6px; padding: 12px; text-align: center;">
        <div style="font-size: 0.8em; color: #7F8C8D;">Annual Transmission Cost</div>
        <div style="font-size: 1.6em; font-weight: bold; color: #E67E22;">${formatCost(annualCost)}</div>
      </div>
      <div style="background: var(--bs-light, #f8f9fa); border-radius: 6px; padding: 12px; text-align: center;">
        <div style="font-size: 0.8em; color: #7F8C8D;">Reduction vs 1-min</div>
        <div style="font-size: 1.6em; font-weight: bold; color: #16A085;">${storageReduction}%</div>
      </div>
    </div>
    <div style="background: ${privacyLevel.color}22; border-left: 4px solid ${privacyLevel.color}; border-radius: 4px; padding: 10px 14px;">
      <strong style="color: ${privacyLevel.color};">Privacy Risk: ${privacyLevel.label}</strong>
      <span style="margin-left: 8px; font-size: 0.9em;">${privacyLevel.desc}</span>
    </div>
  </div>`;
}

15.4.3 Edge Processing for Data Minimization

Processing data on the device (at the edge) before transmission is a powerful data minimization technique:

Processing Location	Data Transmitted	Privacy Level	Example
Cloud Processing	All raw sensor data	Low	Upload all audio to cloud for analysis
Edge Processing	Only results/summaries	High	Detect wake word locally, upload only command
Federated Learning	Model updates only	Very High	Train ML locally, share only gradients

15.5 User Rights in IoT Systems

GDPR and similar regulations grant users specific rights over their personal data. IoT systems must implement mechanisms to fulfill these rights.

15.5.1 The Core User Rights

Right	GDPR Article	Description	IoT Implementation Challenge
Access	Art. 15	See what data is collected	Data spread across device, gateway, cloud
Rectification	Art. 16	Correct inaccurate data	Sensor data is what it is – hard to “correct”
Erasure	Art. 17	Delete personal data	Data in backups, third parties, device caches
Portability	Art. 20	Export data in usable format	Proprietary formats, fragmented ecosystems
Restriction	Art. 18	Limit how data is processed	Continuous collection makes pausing difficult
Object	Art. 21	Refuse certain processing	Device may stop working without data

15.5.2 Implementing Right to Access

Users must be able to see what data IoT systems have collected about them:

15.5.3 Implementing Right to Data Portability

Users have the right to receive their data in a “structured, commonly used and machine-readable format”:

Format	Pros	Cons	Best For
JSON	Universal, human-readable	Verbose, no schema validation	API integrations
CSV	Spreadsheet compatible	Limited data types	Simple sensor data
XML	Schema validation	Verbose, complex	Regulated industries
Parquet	Efficient, typed	Binary, needs tools	Large datasets

15.6 Privacy by Design for IoT

Privacy by Design requires embedding privacy into IoT systems from the beginning, not adding it as an afterthought.

15.6.1 The 7 Foundational Principles

Principle	IoT Application	Good Example	Bad Example
1. Proactive	Anticipate privacy risks during design	Privacy Impact Assessment before launch	Adding “delete data” button after breach
2. Default	Privacy-protective settings out of box	Cloud sync OFF by default	Analytics ON, buried opt-out
3. Embedded	Privacy in architecture, not bolt-on	On-device processing built into chip	Encryption added after beta
4. Full Functionality	Privacy AND features	Federated learning for personalization	“Disable tracking = limited features”
5. End-to-End	Protect entire data lifecycle	Auto-delete after retention period	Forgot to delete backups
6. Transparency	Clear about data practices	Plain-language privacy dashboard	50-page legal privacy policy
7. User-Centric	Respect user choices	Granular consent controls	All-or-nothing consent

15.6.2 Privacy Impact Assessments for IoT

Before launching an IoT product, conduct a Privacy Impact Assessment (PIA):

PIA Phase	Key Questions	IoT Considerations
1. Data Inventory	What data is collected?	Sensors may collect more than intended
2. Data Flows	Where does data go?	Device -> Gateway -> Cloud -> Third parties
3. Necessity	Is each data element needed?	Challenge assumptions about data requirements
4. Risks	What could go wrong?	Breach, re-identification, function creep
5. Mitigations	How to reduce risks?	Minimize, anonymize, encrypt, limit access
6. Documentation	Record decisions	Required for GDPR accountability

15.7 IoT-Specific Privacy Challenges

IoT systems face privacy challenges that don’t exist in traditional computing environments.

15.7.1 Challenge 1: Ambient Data Collection

IoT sensors often capture data about people who aren’t the device owners:

Device	Primary User	Bystanders Affected
Smart doorbell	Homeowner	Visitors, delivery drivers, passersby
Voice assistant	Family member who set it up	All household members, guests
Wearable camera	Wearer	Everyone in camera view
Smart office sensors	Employer	Employees, visitors

15.7.2 Challenge 2: Inference and Re-identification

Even “anonymous” IoT data can reveal identities:

Diagram of a privacy-preserving data flow for smart city IoT, showing the sequential pipeline stages: raw data collection, anonymization processing, data aggregation, analytics computation, and public dashboard output, illustrating how personal identifiers are removed at each stage — Figure 15.5: Privacy-preserving smart city data flow showing the pipeline from raw data through anonymization and aggregation to analytics and public dashboards

15.7.3 Challenge 3: Multi-Party Privacy

IoT ecosystems involve multiple parties with different privacy interests:

Party	Privacy Interest	Conflict Example
Device Owner	Control over own data	vs. Manufacturer wanting usage analytics
Household Members	Privacy in shared space	vs. Owner’s security monitoring
Visitors/Guests	Not being recorded	vs. Homeowner’s smart doorbell
Manufacturer	Product improvement data	vs. User’s data minimization preference
Third-Party Services	Personalization data	vs. User’s portability rights

Worked Example: GDPR-Compliant Smart Doorbell Consent

Scenario: A smart doorbell company collects video of visitors. Under GDPR, both homeowners (who install the device) and visitors (who are recorded without consent) have privacy rights. Design a compliant consent mechanism.

Legal Challenge: Visitors cannot consent (they don’t know they’re being recorded until after). Homeowner controls the device but doesn’t own the visitor’s personal data. Article 6 GDPR requires lawful basis for processing.

Compliant Design Solution:

1. Lawful Basis: Legitimate Interest (Art 6(1)(f))

Homeowner’s interest: Security, property protection
Balanced against: Visitor privacy rights
Requires: Necessity test, proportionality, transparency

3. Transparency Requirements

Visible signage: “Video Surveillance for Security – GDPR Art 13 Notice: Contact [homeowner email]”
Sign placed BEFORE entering camera view (give opportunity to avoid)
Sign includes: Who controls data, purpose, retention period, contact for access requests

4. Technical Controls

Privacy zones: Mask out neighbor’s windows, sidewalk (public areas)
Access controls: Only homeowner can view footage (not shared with manufacturer)
Deletion interface: One-click “Delete all footage” button
Access log: Record every time footage is viewed (audit trail)

6. Multi-Party Conflict Resolution Conflict: Visitor demands erasure vs. Homeowner needs footage for insurance claim

Resolution Framework:

Visitor right to erasure is NOT absolute: Art 17(3) exceptions apply
Homeowner can refuse if: (a) establishing/defending legal claims, (b) compliance with legal obligation
Example: Package stolen 2 days after delivery. Visitor demands erasure. Homeowner refuses citing legal claim (police investigation). This is COMPLIANT.

Testing Compliance:

Ask 5 neighbors: “Did you know the doorbell records video?”
If <80% aware -> signage insufficient
Test data access: Request your own footage -> Should receive within 30 days
Test deletion: Request deletion -> Verify footage actually removed (not just “marked deleted”)

Key Insight: GDPR for IoT cameras is about BALANCE – homeowner security interest vs visitor privacy rights. Compliance requires: transparent signage, data minimization, easy access/deletion, and proportionate retention. It does NOT require asking every visitor for explicit consent (legitimate interest is lawful basis).

Decision Framework: Choosing GDPR Lawful Basis for IoT Data

Lawful Basis	When to Use	Example IoT Application	Limitations
Consent (Art 6(1)(a))	User voluntarily shares data for specific purpose	Fitness tracker sharing health data with research study	Must be freely given (not bundled with service), specific, informed, withdrawable
Contract (Art 6(1)(b))	Processing necessary to provide contracted service	Smart thermostat processing temperature to control HVAC	Cannot justify third-party sharing or analytics beyond core service
Legal Obligation (Art 6(1)(c))	Required by law	E911 location data to emergency services	Narrow scope – only what law mandates
Vital Interests (Art 6(1)(d))	Life-or-death emergency	Medical alert device calling ambulance	Rarely applies – only true emergencies
Public Task (Art 6(1)(e))	Public authority performing official function	City traffic sensors for road management	Only for government/public entities
Legitimate Interest (Art 6(1)(f))	Controller’s interest balanced against user rights	Security camera for property protection	Requires balancing test, transparency, user can object

Decision Algorithm:

Step 1: Can service work without this data?

YES -> Need consent (data not necessary for service)
NO -> Consider contract or legitimate interest

Step 2: Is data needed to fulfill user’s request?

YES -> Contract (Art 6(1)(b))
- Example: User asks thermostat to “set to 72” -> Processing temperature is necessary for service
NO -> Cannot use contract basis

Step 3: Is processing in user’s interest?

YES -> Legitimate interest (Art 6(1)(f)) with balancing test
- Example: Security camera protects user’s property (their interest too)
NO -> Need consent

Step 4: Is it sensitive data (health, biometric, location)?

YES -> Higher scrutiny, consent usually required
NO -> Legitimate interest more defensible

Common Mistake: Consent Bundling and Service Denial

The Mistake: A smart fitness tracker shows this during setup: > “To use this device, you must agree to: > - Health data collection for fitness tracking [Required] > - Sharing data with third-party analytics partners [Required] > - Personalized advertising based on your activity [Required] > [Accept All] [Do Not Use Device]”

Why This Violates GDPR:

Not Freely Given (Art 7(4)): Consent bundled with service access is not free. Users have no real choice.
Not Specific: Three different purposes (tracking, analytics, ads) lumped into one consent
Not Granular: Cannot consent to tracking but refuse ads

What GDPR Requires:

Core service functions (fitness tracking) can use contract basis (Art 6(1)(b)) – no consent needed
Third-party sharing requires separate, optional consent
Ads require separate, optional consent
User can refuse optional items and still use device

The Fix – Granular Consent: > Required for Device to Work: > - Fitness tracking (steps, heart rate) – stored on your device [No consent needed – necessary for service] > > Optional – You Choose: > - Share anonymized data with research partners to improve health algorithms > - Personalized recommendations based on your fitness patterns > - Targeted ads from fitness brands > > [Continue with Selected Choices]

Real-World Example – WhatsApp (2021):

WhatsApp forced users to accept new terms sharing data with Facebook (now Meta)
“Accept or stop using WhatsApp” ultimatum
Irish DPC ruling: This violates GDPR (not freely given)
Irish DPC fine: EUR 225 million for WhatsApp Ireland’s transparency failures
Lesson: Cannot hold service hostage to force consent

Testing Your Consent: Ask: “Can user refuse this consent and still use core device functions?” - If NO -> Consent is not freely given (GDPR violation) - If YES -> Consent is valid (but must be specific, informed, withdrawable)

Special Case – Children:

Children under 16 (varies by country 13-16) require parental consent
IoT toys, educational devices, fitness trackers for kids must verify age
Cannot bundle consent with gameplay/features children want
Violation example: “Sign up for ads to unlock game levels”

Common Pitfalls

1. Using pre-checked consent boxes or consent-by-default

GDPR and CCPA explicitly prohibit implied or automatic consent for personal data collection. Pre-checked checkboxes, buried opt-out links, and ‘continuing to use this service means you consent’ language are all invalid consent mechanisms. Each distinct data collection purpose must have an explicit, active affirmation by the user – typically an unchecked checkbox that the user must actively check.

2. Collecting more data than the stated purpose requires

IoT privacy compliance requires data minimization: if the stated purpose is ‘improving environmental monitoring’, collecting precise device location, usage patterns, and behavioral data goes beyond that purpose and requires separate consent. Data that was consent-based for one purpose cannot be repurposed without new consent. Build data models that enforce purpose limitation at the schema level, not just as a policy.

3. Not providing a clear data deletion mechanism

GDPR Article 17 grants users the ‘right to erasure’ – users must be able to request deletion of their IoT data. Without a technical mechanism to identify and delete all data associated with a specific user across all databases (time-series, document store, backups), IoT platforms face regulatory non-compliance. Design user data deletion as a first-class feature, not an afterthought, including cascade deletion from backup systems.

Label the Diagram

💻 Code Challenge

Order the Steps

Match the Concepts

15.8 Summary and Key Takeaways

15.8.1 Privacy Consent Checklist for IoT

For Kids: Meet the Sensor Squad!

The Sensor Squad learns about asking permission before collecting information!

15.8.2 The Sensor Squad Adventure: The Permission Slip

The Sensor Squad had built an amazing classroom helper that tracked how much each student participated. But then something unexpected happened.

“Hey!” said student Maya. “I didn’t say you could watch me all day! That feels weird.”

Sammy the Sensor was confused. “But I’m helping the teacher know who needs more encouragement!”

Bella the Battery explained: “Sammy, imagine if someone followed YOU around writing down everything you did – where you went at recess, who you talked to, what you ate for lunch. Would you like that?”

“No way!” said Sammy. “That would be creepy!”

Max the Microcontroller pulled out a big piece of paper. “We need a PERMISSION SLIP – just like when you go on a field trip! It should say:

WHAT we collect: ‘We count how many times you raise your hand’ (not ‘we watch everything you do’)
WHY we collect it: ‘To help the teacher make sure everyone gets a turn’
WHO sees it: ‘Only your teacher, nobody else’
HOW to say NO: ‘You can opt out anytime by telling the teacher’
HOW to DELETE it: ‘At the end of the week, we erase everything’”

Lila the LED added the most important rule: “And ‘No’ must be a real option! If Maya says no, she should still get the same education. Consent means you have a REAL choice, not ‘agree or else!’”

Maya read the permission slip and smiled. “NOW I understand what you’re doing and why. I’m okay with counting hand-raises. But please don’t track where I sit or who I talk to – that’s none of your business!”

“Deal!” said the Squad. “That’s called DATA MINIMIZATION – only collecting what you actually need!”

15.8.3 Key Words for Kids

Word	What It Means
Consent	Giving permission after you understand what will happen with your information
Data Minimization	Only collecting the smallest amount of information you truly need
Opt Out	Being able to say “No, thanks” without being punished
Privacy by Design	Building privacy protection into a system from the very beginning

15.9 Concept Relationships

Privacy and user consent in IoT connect to broader system design concepts:

Consent mechanisms are a specific application of user authentication and access control patterns
Data minimization mirrors the design principle of “least privilege” from security architecture
Privacy by Design parallels “security by design” and “accessibility by design” as proactive architectural approaches
GDPR compliance intersects with device lifecycle management (data retention, right to erasure requires deletion workflows)
Edge processing for privacy aligns with fog/edge computing architectures that reduce data transmission

Understanding consent and privacy reveals how legal/regulatory requirements shape technical architecture choices – privacy isn’t just a legal checkbox but a fundamental design constraint like power or bandwidth.

15.10 See Also

Privacy by Design Schemes: Deep dive into the 7 foundational Privacy by Design principles with implementation patterns
Security and Privacy Overview: Broader context on how privacy and security intersect in IoT systems
User Experience Design: Learn how UX principles apply to designing transparent, user-friendly consent interfaces
Data Storage and Management: Understand how data retention policies and deletion workflows enable GDPR compliance

Match: Key Concepts

Order: Process Steps

Previous	Up	Next
Location Privacy	Accessibility	UX Accessibility

15.12 What’s Next

If you want to…	Read this
Understand location privacy specifically for GPS IoT data	Location Privacy and Consent
Design accessible consent interfaces for IoT applications	Interface and Interaction Design
Apply accessibility and inclusion in UX design for IoT	UX Design Accessibility
Understand IoT security and authentication frameworks	Security Fundamentals
Build privacy-respecting IoT data storage architectures	Data Storage Overview