HIPAA technical safeguards. In production.
Every §164.312 technical safeguard implemented and verified, not aspirational. AES-256-GCM PHI at rest, mask-by-default API with audited reveal, RS256 passport, boot-time secret guard, row-level RBAC, and a separate PHI access log capturing actor, role, IP, and timestamp on every read. The same architecture ships in Credential OS. Honest about what we have built and honest about what HIPAA compliance also requires beyond the technical controls.
Six controls. Every clause cited.
HIPAA §164.312 lists six technical-safeguards categories. We implement all six, with implementation evidence per control. The chart on the right names each control by clause and shows the practical implementation. The evidence is real production code, verified by Credential OS UAT in June 2026 (74 of 74 passing).
Technical safeguards are necessary but not sufficient for HIPAA compliance. The administrative controls under §164.308 (workforce training, sanction policy, contingency planning) and physical controls under §164.310 (facility access, workstation security) are organizational practices that sit alongside the technical implementation. We are explicit with every customer that technical implementation is one of three categories, and a full compliance posture also requires BAAs, HIPAA-eligible hosting, and independent penetration testing.
Every PHI access. Append-only.
The PHI access log is what makes §164.312(b) audit controls real. Every read, write, reveal, and export of PHI writes a row. Actor, role at access, source IP, timestamp, record class, action, and the application context. Exportable for audit. Retention-policy controlled. Below is the redacted view.
Six capabilities. Every safeguard real.
Each capability is production code, shipped in Credential OS and reused across the AR Workflow, Coding Engine, and Reporting Cloud. The architecture below is the discipline that makes the §164.312 implementation hold up under audit.
AES-256-GCM, column-level.
Every PHI column (SSN, TIN, DOB, taxpayer-ID, sensitive credentialing fields) encrypted with AES-256-GCM. Per-tenant data-encryption keys wrapped by an envelope KEK. Authenticated encryption: tampered ciphertext fails decryption rather than returning corrupted plaintext. Disk-level encryption underneath; column-level is what protects against logical-access compromise.
Reveal endpoint, audited.
The default API response masks PHI fields with structured masks (XXX-XX-1234). Downstream consumers never accidentally log or display full values. When a caller genuinely needs the unmasked value, they call a separate reveal endpoint. Reveal requires elevated role and writes a row to the PHI access log with actor, role, IP, timestamp, justification, and record accessed.
Asymmetric signing, short TTL.
All inter-service calls and user sessions carry an RS256-signed JWT. RSA with SHA-256 because asymmetric signing means services verify with the public key, no shared secret distribution. Short TTL: 15 minutes for user sessions, 5 minutes for service-to-service. Refresh tokens stored separately with their own audit trail. Compromised passport has a small window.
TLS 1.3, HSTS, CSP.
TLS 1.3 in transit with HSTS preload. Content Security Policy locked to known origins. X-Frame-Options DENY. X-Content-Type-Options nosniff. Strict Referrer-Policy. Cookie attributes Secure, HttpOnly, SameSite Strict on auth cookies. Headers verified on every production deploy by the security UAT suite.
Known-bad defaults, hard fail.
On service boot, the app checks every secret from environment variables against a small set of known-bad defaults (literal 'change-me', empty string, dev-stage JWT signing key in source control). A production-marked deploy loading a known-bad default exits with a clear log line and non-zero status. Prevents the most common cause of shipping a production deploy with a default secret.
Append-only audit, scoped by row.
Separate append-only PHI access log captures every read, write, reveal, export with actor, role, IP, timestamp, record class, action, application context. Retention-controlled, exportable for audit. Authorization enforced at the row level in the data access layer; rows visible only if caller role and tenant scope match. Cannot accidentally see another tenant's data even by URL construction.
Four gates. Every read audited.
From an authenticated request to a PHI field returned. Four gates run on every read. Below is the lifecycle of a single API call asking for a provider's masked TIN.
Passport validated.
Incoming request carries an RS256-signed JWT. Verifier checks signature against public key, expiry, audience, and tenant claim. Invalid passport returns 401 with no PHI context loaded. Valid passport populates the authenticated identity and role context for the request.
RBAC at the row.
Data access layer filters by the caller's tenant scope and role permission for the entity. Query never sees rows the caller is not authorized to see. URL-construction attacks return empty results, not access denial, so the schema is not enumerable. Same filter applied to read, write, reveal, export.
Mask by default.
Authorized row loads. Response serializer applies mask transforms to PHI fields per the configured mask policy. TIN returns XXX-XX-1234, SSN returns XXX-XX-1234, DOB returns YYYY. Unmasked values never enter the response unless the caller invoked the reveal endpoint with elevated role.
Log the access.
Before the response returns, a row writes to the append-only PHI access log: actor, role, source IP, timestamp, record class and ID, action (read or reveal), application context. Log is retention-policy controlled. Exportable for audit. Same log captures the writes and exports on the same record.
Measured posture from the architecture.
Verified by the Credential OS UAT suite. The same architecture ships across the coding engine, AR workflow, and reporting cloud. Numbers below are honest, measured posture.
Frequently asked: security architecture.
What HIPAA technical safeguards are actually implemented?
What does AES-256-GCM PHI at rest mean?
Why mask-by-default on the API and what is an audited reveal?
What is the RS256 passport?
What is the boot-time secret guard?
What is the PHI access log and what does it capture?
How does row-level RBAC actually work?
Are technical safeguards the same as being HIPAA compliant?
Where the architecture shows up.
The same security architecture ships across the platform. Three places it is most visible.
The reference implementation.
Credential OS is the platform where the §164.312 controls live in production. UAT 74 of 74 passing in June 2026. NCQA-ready credentialing with row-level RBAC, AES-256-GCM PHI at rest, and the PHI access log in the same audit posture documented here.
Read more → API + FHIRPassport and mask-by-default.
The API surface enforces RS256 passport at the gateway, mask-by-default on every PHI field, and writes the access log row before the response returns. Same security gates documented here apply to every external integration.
Read more → Coding engineAudit trail per coded line.
The coding engine writes the same audit-trail row design per line: rule fired, actor, timestamp, IP, documentation snippet. Reuses the row-level RBAC and tenant-scope filtering. One discipline across the platform.
Read more →Need the security packet for IT review? Send us the questionnaire.
We will return a security posture document covering §164.312 implementation evidence per control, the Credential OS UAT report, the architectural diagrams for PHI flow and access control, and a frank statement of what is in scope (technical safeguards), what is in progress (independent pen test, hosting BAAs), and what we cannot claim. An ASP-RCM senior partner on the call.