HIPAA Technical Safeguards on iOS: 45 CFR § 164.312 to ScreenGuard

If your iOS app handles protected health information (PHI), telehealth, patient portals, EMR access, lab results, clinical trial software, the HIPAA Security Rule’s Technical Safeguards (45 CFR § 164.312) is a compliance document you have to satisfy. It is also one of the most engineering-frustrating documents in the federal corpus: it specifies controls in deliberately abstract language to remain technology-neutral, which is fine if you’re an auditor and unhelpful if you’re an engineer trying to ship a build.

This post is the mapping that bridges the gap: each numbered safeguard in § 164.312, the iOS engineering control that satisfies it, and a flag for whether ScreenGuard’s .hipaa configuration preset implements it out of the box. The framework is what you write down in your Security Risk Analysis to point at this control, not legal advice. For the legal advice, work with your compliance counsel; for the engineering, read on.

The four required safeguards and four addressable ones, in order:

§ 164.312(a)(1), Access Control (Required)

Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights.

iOS engineering control: authentication gating + per-view authorization. The app authenticates the user (Face ID / Touch ID / passcode at minimum) and then authorizes specific data accesses against the user’s role.

ScreenGuard’s role: not the access-control primary, but supports it via biometric per-view gating (SGBiometricGate). Use this to add a fresh biometric prompt to specific protected views (chart access, lab results) on top of the app’s general session authentication.

.hipaa preset: ✓ (biometric per-view gating wired by default; the integrator chooses which views opt in).

§ 164.312(a)(2)(i), Unique User Identification (Required)

Assign a unique name and/or number for identifying and tracking user identity.

iOS engineering control: the application assigns a unique user identifier and includes it in every audit log entry. The user ID is the audit log’s primary key.

ScreenGuard’s role: the watermark identity (SGWatermarkIdentity.userIdentifier) carries this through to every protected view and every forensic verification. The audit log emitted by SGEventListener includes the user ID on every event.

.hipaa preset: ✓ (every audit event tagged with user identifier).

§ 164.312(a)(2)(ii), Emergency Access Procedure (Required)

Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.

iOS engineering control: a documented break-glass procedure that allows specific users to access PHI without their normal authorization, with audit. Typically implemented as a separate role with elevated access that logs every action.

ScreenGuard’s role: emit .breakGlassActivated events into the audit stream when the app enters emergency mode. ScreenGuard does not implement the break-glass workflow, that’s app-level, but the audit primitive supports the evidence requirement.

.hipaa preset: partial (audit primitive ready; the workflow is the integrator’s).

§ 164.312(a)(2)(iii), Automatic Logoff (Addressable)

Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

iOS engineering control: idle-timeout monitor that locks or logs the user out after a configurable inactivity period.

ScreenGuard’s role: SGIdleTimeoutMonitor ships exactly this. The .hipaa preset configures a 10-minute idle threshold with .logout as the action.

.hipaa preset: ✓ (10 minutes idle → automatic logoff, configurable to other thresholds via the builder).

§ 164.312(a)(2)(iv), Encryption and Decryption (Addressable)

Implement a mechanism to encrypt and decrypt electronic protected health information.

iOS engineering control: at-rest encryption (Data Protection + Keychain) plus in-transit encryption (TLS 1.2+ with certificate pinning). At the screen layer, this maps to the secure rendering canvas that scrubs framebuffer content from capture pipelines.

ScreenGuard’s role: the hardware-shielded canvas (ScreenGuardContainerView wrapping a UITextField secure rendering surface) is the on-screen analog of encrypted-at-rest, content is rendered into a surface the OS does not expose to ReplayKit / AirPlay / screenshot capture.

.hipaa preset: ✓ (hardware shield mandatory on every protected view).

§ 164.312(b), Audit Controls (Required)

Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

iOS engineering control: tamper-evident audit log of every access to PHI, including who accessed what, when, from which device.

ScreenGuard’s role: SGSecurityEvent audit stream forwarded to SGSIEMForwarder writes every capture event, protection activation, idle elapse, environment-compromise signal, and watermark-render event to your audit backend. The audit log is signed by the SDK and tamper-evident at the event-payload level.

.hipaa preset: ✓ (every event captured; SIEM forwarder optional but pre-wired).

§ 164.312(c)(1), Integrity (Required)

Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

iOS engineering control: hash-chained audit log so any tampering with the audit record itself is detectable. Plus, for the data being viewed, a way to verify the data has not been altered between server and screen.

ScreenGuard’s role: the audit chain produced by SGSecurityEvent events is SHA-256 chained, HMAC-signed at append time. Verifying the chain is one call; a broken chain points at the exact event where the chain broke.

.hipaa preset: ✓ (hash-chained audit log).

§ 164.312(c)(2), Mechanism to Authenticate Electronic Protected Health Information (Addressable)

Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.

iOS engineering control: HMAC or signature on PHI records, verified at display time. The display surface confirms integrity before rendering.

ScreenGuard’s role: forensic watermarks include the data-record identifier in the watermark identity, so a leaked screenshot can be cross-referenced with the audit log to confirm what record was viewed at what time. This is corroboration via attribution, different mechanism, same compliance objective.

.hipaa preset: ✓ (watermark identity includes record correlator).

§ 164.312(d), Person or Entity Authentication (Required)

Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

iOS engineering control: biometric authentication (Face ID / Touch ID), passcode, optionally MFA via App Attest or a federated identity provider.

ScreenGuard’s role: not the primary, the app’s auth flow handles this. ScreenGuard’s role is to re-verify via biometric per-view gates for specific high-sensitivity records.

.hipaa preset: ✓ when SGBiometricGate is wired to a protected view; off by default since not every PHI access needs re-prompt.

§ 164.312(e)(1), Transmission Security (Required)

Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

iOS engineering control: TLS 1.2+ with certificate pinning, ATS enabled, no NSAllowsArbitraryLoads.

ScreenGuard’s role: not relevant, transmission security is the network layer’s job. Pair with PayloadGuard for the transmission-security side.

.hipaa preset: N/A (different SDK).

§ 164.312(e)(2)(i), Integrity Controls in Transit (Addressable)

Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.

iOS engineering control: HMAC/signature on every PHI record in transit; verify on receipt before rendering.

ScreenGuard’s role: not relevant, same as above, this is PayloadGuard’s territory.

.hipaa preset: N/A.

§ 164.312(e)(2)(ii), Encryption in Transit (Addressable)

Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.

iOS engineering control: TLS 1.2+ as the floor; TLS 1.3 where the server supports it.

ScreenGuard’s role: N/A.

What the .hipaa preset actually configures

Walking down the list, the .hipaa preset implements:

Safeguard	Mechanism	Preset value
(a)(2)(iii), Auto Logoff	SGIdleTimeoutMonitor	600s / .logout
(a)(2)(iv), Encryption/decryption (screen layer)	ScreenGuardContainerView hardware shield	mandatory
(b), Audit Controls	SGSecurityEvent stream	every event
(c)(1), Integrity	Hash-chained audit log	SHA-256 + HMAC
(c)(2), Authentication of PHI	Forensic watermark with record correlator	required, .standard style
Pasteboard policy (implicit)	SGPasteboardGuard	strict (block copy/cut/share menu)
App-switcher snapshot blur	SGAppLifecycleGuard	blurred for protected views

The preset is a one-line apply (.applyPreset(.hipaa)), and you override individual settings via the builder if your interpretation of the safeguard differs (e.g., your security risk analysis allows a 15-minute idle threshold instead of 10).

What you still have to do at the app level

Three safeguards the preset cannot satisfy alone, because they are workflow rather than primitive:

• Emergency access procedure, you need to design and document the break-glass workflow. ScreenGuard’s audit primitive captures evidence; the workflow is yours.
• Person authentication, your app’s authentication flow needs to satisfy this. ScreenGuard adds per-view biometric prompts as a layer.
• Unique user identification, your back-end needs to issue unique IDs. ScreenGuard propagates them into every audit event and every watermark.

The right framing: ScreenGuard’s .hipaa preset is the screen-layer implementation of the Technical Safeguards. The transmission-layer side belongs to PayloadGuard, the runtime-defense layer to RuntimeGuard SDK, the authentication-layer to your app and Apple’s biometry. The full HIPAA-compliant iOS app is a composition of these, .hipaa is the configuration that makes ScreenGuard’s contribution to the composition correct.

For the documentation auditors actually want, the mapping from each safeguard to your specific control, copy the table above into your Security Risk Analysis, citing the SDK version and preset name. That mapping satisfies HHS-OCR auditor’s “show me which control implements each safeguard” question, which is the most common HIPAA technical-audit ask.

See /sdk/screenguard for the marketing summary, /docs/screenguard for the preset reference, the ScreenGuard threat model for the attacker capabilities behind each safeguard, and the companion posts on forensic HMAC watermarks and UIScreen.isCaptured for the threat-model context.