Temporal for HIPAA ePHI in workflow payloads

The codec is where ePHI in a Temporal workflow payload becomes ciphertext, and it is also where that ciphertext can become readable again. Payloads pass through a custom codec before they leave the client, and the Web UI can decode them through a codec server endpoint. That makes encryption keys and decryption rights a design decision, not a configuration detail. Under 45 CFR 164.312(a)(2)(iv), encryption and decryption is an addressable implementation specification. You must assess whether it is reasonable and appropriate for your workflows, and if you do not implement it as written, document why and adopt an equivalent measure. Record that assessment before the codec is built.

Key management comes first. Decide where keys are generated, stored and rotated, and whether they sit in a managed key service in your cloud account, a key manager in your data center, or a secrets platform you operate. Use separate keys for each environment and each data class so a development codec cannot decrypt production payloads. Confirm how rotation affects long-running workflows that still hold payloads encrypted under an older key, and how keys are backed up and recovered. Ask your team or your implementation partner to document which key systems the codec implementation supports and who holds the key administration role.

Next, map which identities may decrypt. Workers run workflow and activity code, so they need the codec to read their inputs. Operators, support staff and auditors need decoded data only for specific tasks, and the Web UI decodes on behalf of whoever is signed in. List each identity type: worker service accounts, operators, support, auditors and any automation. Then use a ClaimMapper to map JWT or certificate claims to namespace roles, and replace the default noopAuthorizer, which allows every API request, with an Authorizer plugin. The TEMPORAL_AUTH_ENABLED setting controls sign-in to the interface but not authorization against the Temporal Service, so a signed-in user still needs Authorizer rules that match the roles you defined.

The codec server is a high-value target because it decrypts on request. Keep it on hosts that are not reachable from the public internet, restrict network access to trusted internal networks, and require authentication before any decode request is served. Use mTLS for internode and frontend traffic and confirm that the codec endpoint is covered by the same trust model. Log decode requests so access can be reviewed against 45 CFR 164.312(b). Then confirm what the codec does not cover. The supplied facts do not describe encryption at rest for the persistence database or the visibility store. Confirm how your chosen Cassandra, PostgreSQL or MySQL persistence and Elasticsearch, OpenSearch or SQL visibility store encrypt data at rest, and whether search attributes or memos in clear text could carry ePHI.

The first control to fix is the Authorizer. If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. Any process that can reach the frontend can start, signal, query or terminate workflows, including workflows that carry ePHI. That alone defeats the access requirement in 45 CFR 164.312(a)(1), which calls for technical policies so that only persons or software programs granted access rights can reach ePHI. Payload encryption does not fix this, because a caller who can reach the API can still read workflow history or act on running executions. Treat a configured Authorizer as a gate that must pass before any ePHI is routed to the cluster.

The ClaimMapper turns caller identity into namespace permissions. Self-hosted Temporal can map JWT claims or certificate claims to namespace roles, and the Authorizer plugin evaluates those roles on each request. Decide which identity source is authoritative for each caller type before writing mapping logic. Human operators, workers and application clients usually need different identities. Workers run as services, so a certificate or token issued to a named service account is easier to audit than a shared credential. Confirm the exact claim fields and role names in the security documentation for your server version, because the mapper must match what your identity provider actually issues. Grant each caller the lowest role it needs.

Namespace separation is the boundary your authorization model depends on. Organize namespaces around data sensitivity, not team structure. Place ePHI workloads in dedicated namespaces with their own workers, roles and retention settings, and keep non-ePHI workloads out of them. Because roles are granted per namespace, a caller with rights to a general namespace should have no path into the ePHI namespace. Also check what workflow metadata the Web UI and visibility queries expose, since search attributes may carry identifiers. Keep a current inventory of which namespaces hold ePHI, because audit controls under 45 CFR 164.312(b) depend on knowing where ePHI lives.

Test the refusal before go-live, and repeat the test after every server upgrade or mapper change. Create test identities with no roles, a token from an unrelated issuer, a certificate signed by another certificate authority, and a valid identity holding only a read role. Attempt start, signal, query and terminate operations against the ePHI namespace. Each unauthorized call should fail, and the failure should appear in server logs that your team reviews. Confirm that frontend and internode traffic is protected with mTLS, which supports 45 CFR 164.312(e)(1). Keep the results with your risk analysis. HHS does not certify HIPAA compliance, so this evidence supports your own review and any later assessment.

The HIPAA Security Rule applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all electronic protected health information they create, receive, maintain or transmit. Temporal configuration covers only part of that obligation. The technical safeguards in 45 CFR 164.312 address access, audit controls, integrity, authentication and transmission security for the Temporal services, but the administrative and physical safeguards in 164.308 and 164.310 still need owners, documented procedures and evidence. Before you design the deployment, confirm with your compliance lead or counsel which entity type you are and whether your workflows make you a business associate of someone else.

Most of the Temporal-related specifications are addressable, not required. For an addressable specification, the entity must assess whether the measure is reasonable and appropriate in its environment. If it is not, the entity must document why and implement an equivalent alternative measure where that is reasonable and appropriate (45 CFR 164.306(d)). Payload encryption under 164.312(a)(2)(iv) is one example. Your written assessment should state how the codec and key arrangement is chosen, who holds decryption rights, and what happens to data that reaches the visibility store, logs or the Web UI in plain form. Record the reasoning even when the outcome is the control you would have chosen anyway.

If a vendor, hosting partner, managed database provider or implementation partner creates, receives, maintains or transmits ePHI for you, 45 CFR 164.314(a)(2)(i) requires a business associate contract. That contract must require the business associate to comply with the Security Rule, flow the same terms to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. Ask each party whether anyone on their side can see decrypted workflow payloads, who can reach the Temporal namespaces, and where backups and support artifacts are stored. Have counsel review whether the contract language matches those answers.

HHS states that no Security Rule standard requires an entity to certify compliance and that it does not endorse or recognize private certifications, which also do not prevent HHS from later finding a violation (HHS FAQ 2003). Treat any vendor claim of HIPAA certification as a statement to verify, not as evidence. The HHS Office for Civil Rights enforces the rule through complaint investigations, compliance reviews and audits. Its 2024 to 2025 HIPAA audits review 50 covered entities' and business associates' compliance with provisions most relevant to hacking and ransomware. The inflation-adjusted civil money penalty for penalties assessed on or after January 28, 2026 ranges from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 (45 CFR 102.3, 91 FR 3666).

NIST SP 800-66 Rev. 2 (February 2024) is a NIST resource guide for implementing the Security Rule. It gives key activities and sample questions for each standard, and HHS lists it as informational rather than legally binding. It is useful for building the risk analysis and test plan for a Temporal deployment. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22). As of October 2026 no final rule has been published, and the latest Unified Agenda projects final action for July 2027. Build the current rule into your assessment now, and ask counsel how a final rule would change the documentation you need to keep.