HIPAA Compliance for Wearable Health Technology Companies: How to Meet Requirements and Protect PHI

HIPAA Applicability to Wearable Companies

When HIPAA applies

HIPAA applies when your company is a covered entity (such as a health care provider transmitting standard transactions) or a business associate that creates, receives, maintains, or transmits Protected Health Information (PHI) for a covered entity. If your wearable collects data on behalf of a hospital, clinic, or health plan under a health program or integration, HIPAA obligations likely attach.

When HIPAA does not apply

Consumer-directed wearables that collect health-related data solely for the user—without a covered entity involved—are generally not subject to HIPAA. In these cases, federal and state consumer protection and privacy laws govern. However, once you exchange, sync, or analyze user data for a covered entity, the same data can become PHI, and HIPAA can apply to those specific flows.

Map your data flows

Create a clear data inventory that labels each collection point, processing activity, and sharing destination. For every flow, determine: Is a covered entity involved? Is a Business Associate Agreement (BAA) in place? Is the data PHI or non-PHI? This mapping guides your compliance scope, contract needs, and technical safeguards.

Business Associate Agreements for Data Sharing

When a BAA is required

A Business Associate Agreement is required when your company—or your subcontractors—handles PHI to perform services for a covered entity (for example, remote monitoring, care management analytics, or EHR integrations). A BAA must be executed before any PHI is exchanged, and it should extend to downstream vendors that also touch PHI.

Core elements to include

• Permitted and required uses/disclosures of PHI, with purpose limitation.
• Administrative, physical, and technical safeguards aligned to the HIPAA Security Rule.
• Breach and security incident reporting obligations, including timelines and cooperation.
• Subcontractor management requiring equivalent protections and flow-down terms.
• Individual rights support (access, amendments, accounting of disclosures when applicable).
• Return or destruction of PHI at contract end, and data retention parameters.
• Audit, monitoring, and termination rights for material violations.

Common pitfalls to avoid

• Mixing PHI and non-PHI datasets without controls, creating unintended HIPAA scope creep.
• Using analytics or advertising tools on PHI environments without explicit authorization and safeguards.
• Engaging subcontractors before ensuring BAA coverage and due diligence.

Encryption Requirements for PHI

How HIPAA treats encryption

Under the HIPAA Security Rule, encryption is an “addressable” safeguard—meaning you must implement it if reasonable and appropriate, or document a comparable alternative. In practice, encryption is strongly expected because it mitigates risk and can reduce breach-notification exposure when properly applied to PHI.

Encryption in Transit and At Rest

• In transit: Use modern TLS (for example, TLS 1.2 or higher) for APIs, mobile apps, and web services. Validate certificates, enforce HSTS where applicable, and disable weak ciphers.
• At rest: Use strong, industry-standard algorithms (for example, AES-256) with proper key management. Encrypt databases, file stores, and device-level storage that could contain PHI.

Key management and validation

Protect cryptographic keys using hardware-backed modules when feasible, rotate keys on a defined schedule, and segregate duties for key custodians. Favor FIPS 140-2/140-3 validated modules to align with federal security expectations for PHI.

Mobile and device considerations

• Enable full-disk encryption on wearable devices and phones that may cache PHI.
• Prevent PHI storage on insecure local caches; prefer secure enclaves or server-side storage.
• Implement secure pairing, mutual authentication, and session timeouts for Bluetooth and Wi‑Fi.

FTC Health Breach Notification Rule

Who is covered

The FTC Health Breach Notification Rule applies to vendors of personal health records (PHRs), PHR-related entities, and their service providers that are not covered by HIPAA. Many direct-to-consumer health apps and wearables can fall under this rule when they aggregate identifiable health information.

What triggers notice

A reportable event includes a breach of unsecured, identifiable health information in a PHR—this can include unauthorized acquisition, disclosure, or use. Improper sharing with third parties (such as analytics or advertising partners) can, in certain circumstances, constitute a breach.

Notification timeline and recipients

• Timing: Provide notices without unreasonable delay and no later than 60 calendar days after discovery.
• Recipients: Affected consumers, the FTC (via its reporting portal), and in some cases the media when a breach affects a large number of residents in a state or jurisdiction.

Coordination with HIPAA

If HIPAA and the FTC rule both could apply due to mixed data environments, coordinate with counsel to determine which notification pathway governs or whether both do. When in doubt, follow the stricter standard and maintain thorough incident documentation.

State Data Protection Regulations

The patchwork you must navigate

State Privacy Laws increasingly regulate health-related, biometric, and precise geolocation data—even outside HIPAA. Comprehensive privacy laws in states such as California, Colorado, Connecticut, Utah, and Virginia impose obligations around notices, consumer rights (access, deletion, correction, portability), data minimization, and opt-outs for targeted advertising and certain profiling.

Health-specific laws

• Some states treat any “consumer health data” as sensitive, requiring opt-in consent and strict purpose limits.
• Biometric and genetic data laws often require written consent, secure storage, and defined retention schedules.
• Data broker and registry statutes may apply if you sell or share covered data about consumers.

Operational takeaways

• Classify data by sensitivity and state-of-residence to drive consent, rights, and retention controls.
• Offer clear, state-specific disclosures and honor universal opt-out mechanisms where required.
• Flow down state requirements to vendors that handle covered data on your behalf.

Implementing Security Measures

Build a risk-based security program

• Perform an enterprise-wide risk analysis covering apps, APIs, devices, and cloud infrastructure; update at least annually and after major changes.
• Adopt written policies and procedures, with workforce training and sanctions for violations.

Access control and Multi-Factor Authentication

• Enforce least-privilege, role-based access, and just-in-time elevation for administrative tasks.
• Require Multi-Factor Authentication for all administrative access and for any user access to PHI.
• Segment environments (production vs. development), and restrict direct database access.

Secure development and testing

• Integrate security into the SDLC with code review, SAST/DAST, dependency scanning, and software bills of materials (SBOMs).
• Conduct regular penetration tests and threat modeling for mobile apps, firmware, and cloud APIs.

Logging, monitoring, and incident response

• Centralize logs, enable tamper-evident storage, and monitor for anomalous behavior.
• Maintain a tested incident response plan with forensic readiness and executive communication playbooks.

Data minimization, retention, and backups

• Collect only what you need, retain it only as long as justified, and document disposal procedures.
• Encrypt and test backups; protect keys separately; validate rapid restoration objectives.

Data De-Identification

• Use HIPAA de-identification pathways: safe harbor (removal of specified identifiers) or expert determination with documented risk analysis.
• Apply differential privacy or aggregation for analytics, and prevent re-identification via governance and technical controls.

Device and firmware safeguards

• Implement secure boot, signed firmware updates, and rollback protection.
• Harden BLE/Wi‑Fi, disable unused services, and sandbox sensitive processes.

Vendor and cloud governance

• Assess vendors for security maturity, require BAAs when PHI is involved, and mandate breach reporting and audit rights.
• Use cloud-native security controls (KMS, IAM, network policies) and validate configurations against benchmarks.

Consumer Consent and Data Transparency

Clear notices and user-first design

Present concise, layered privacy notices that explain what you collect, why you collect it, how long you keep it, and who you share it with. Highlight sensitive data uses (health, biometrics, precise location) and give users easy controls to manage preferences.

Granular, opt-in consent for sensitive data

Obtain unambiguous, granular consent for sensitive uses such as continuous location tracking, sharing with third parties, or targeted advertising. Avoid dark patterns; make withdrawal of consent as easy as giving it.

Managing analytics and advertising technologies

Evaluate SDKs and pixels before deployment. Disable cross-context behavioral advertising on PHI properties and other sensitive contexts unless you have a lawful basis and robust safeguards. Use contracts and technical measures to prevent unauthorized re-use of data.

Respect consumer rights

Provide self-serve portals for access, correction, deletion, and portability. Authenticate requests proportionately, track deadlines, and document fulfillment. Communicate retention schedules and automatically delete data when no longer necessary.

FAQs.

Are wearable health technology companies always subject to HIPAA?

No. HIPAA applies when you are a covered entity or a business associate handling PHI for a covered entity. Direct-to-consumer wearables operating without a covered entity are generally outside HIPAA but remain subject to the FTC and State Privacy Laws. If you later integrate with a hospital or plan and exchange PHI, HIPAA obligations can attach to those specific data flows.

What are the key encryption standards required under HIPAA?

HIPAA designates encryption as an addressable safeguard, but industry practice is to use strong, modern cryptography. Implement Encryption in Transit and At Rest—such as TLS 1.2/1.3 for data in transit and AES-256 for data at rest—along with robust key management. Favor FIPS 140-2/140-3 validated modules and document configurations and key rotations.

When is a Business Associate Agreement necessary?

You need a Business Associate Agreement when your company—or your subcontractors—creates, receives, maintains, or transmits PHI to perform services for a covered entity. No BAA is required for purely consumer-directed services with no covered entity involvement or for datasets that have been properly de-identified under HIPAA.

How do state laws affect wearable companies' data protection requirements?

State Privacy Laws can impose obligations regardless of HIPAA status, including clear notices, rights to access and delete data, opt-outs for targeted advertising, and opt-in consent for sensitive data such as health, biometrics, and precise location. Some states also regulate “consumer health data,” biometrics, and data brokers, requiring additional disclosures, contracts, and retention limits.