A working SAML login does not prove that PHI access is controlled. I use this checklist to verify each app’s trust settings, role permissions, logs, and recovery paths - and assign an owner and deadline to every failed check.
Here’s what I review across clinical apps:
- Connections and recovery: List every app, owner, user group, and outage recovery path.
- SAML trust: Check metadata, signing keys, key rotation, assertion checks, MFA, and session limits.
- PHI access: Test allowed and denied actions, role changes, account removal, and log protection.
- Emergency access: Test named, time-limited access and remove temporary privileges after recovery.
- Vendor duties: Review support access, PHI agreements, reporting deadlines, and risk records.
- Approval and retesting: Record results, approved risks, remediation dates, and change-triggered tests.
My rule: <u>approve the tested setup, not just a successful login</u>. Set certificate reminders 60 days before expiration, and keep downtime recovery separate from emergency access.
Healthcare SAML Audit: Six Checks Before Approval
Enterprise SAML SSO Deep Dive: Trust Setup to Auth Code Generation
sbb-itb-535baee
Check Metadata, Certificates, and Assertions
For every inventoried application and environment, compare live IdP and SP settings against the approved trust record for that connection.[6][7] Keep SAML signing trust separate from HTTPS/TLS trust. Use the correct certificate model, and base chain and validity checks on SAML trust rules - not HTTPS rules.[11][15]
Verify Metadata and Certificate Rotation
☐ IAM and SP administrators: Check securely exchanged metadata and confirm that production values match the approved record.[6][7] Validate metadata signatures using a trusted verification key restricted to the intended source.[15] Use the matrix below to record approved and observed values, discrepancies, and dated evidence.
Metadata and Certificate Evidence Matrix
| Application/environment | Control | Supporting records | Result | Metadata or certificate expiration date | Owner | Remediation deadline |
|---|---|---|---|---|---|---|
| Each connection | Metadata matches approved settings | Verified metadata, configuration exports, approved/observed entity IDs, HTTPS ACS and logout URLs, SSO endpoints, bindings, NameID formats, discrepancies, test date and time (U.S. format) | Pass/fail | Metadata or certificate expiration date | IAM/SP administrator | Required for failures |
| Each connection | Signing trust matches approved model | Pinned public key, approved certificate, or defined certificate chain; fingerprints, certificate validity dates, algorithms, key lengths, trust configuration | Pass/fail | Signing certificate expiration date | Signing-key owner | Required for failures |
| Each connection | Rotation and retirement work | Change ticket, nonproduction rollover results, overlap and rollback plan, production authentication results, new-key acceptance, retired-key rejection, and stale-metadata test logs | Pass/fail | Current and next certificate dates | Rotation owner | Required for failures |
☐ Rotation owner: Publish and test the next key before retiring the current one. Test rollover in nonproduction and authentication in production during the approved overlap period. Confirm that stale metadata cannot re-enable the retired key. Pass only when settings match, rotation has been tested, and retired keys are rejected. Set expiration alerts and keep the rollback record.[11][12]
Test Signature and Assertion Checks
☐ IAM and application security: Confirm that the application accepts only a valid signed assertion from the approved IdP. Check the issuer, destination, recipient, audience restriction, subject confirmation, NotBefore, NotOnOrAfter, clock synchronization, and clock-skew tolerance. For SP-initiated login, verify required request signing and InResponseTo correlation. Assess permitted IdP-initiated flows separately. Use stable user identifiers and remove unnecessary PHI attributes.[13][14]
☐ Run controlled negative tests for unsigned or altered assertions, incorrect endpoints or audiences, invalid time limits, mismatched request IDs, replay, and signature wrapping. Resubmit a captured test assertion; the second submission must fail. Also test an assertion that pairs a valid signed element with an unsigned malicious element. The application must not consume the attacker-controlled content. Pass only when invalid inputs create no session and generate logs showing the test ID, timestamp, expected result, and actual result. Protect captured assertions as sensitive evidence.[9][14]
Test MFA and Session Controls
☐ IAM and application owners: Test standard user, privileged user, remote user, and step-up access flows, including MFA failure and step-up denial. Verify the requested authentication context and what the application enforces. Test idle and absolute session limits, reauthentication, account disablement, administrative revocation, and supported logout flows. Check whether SP cookies and backend sessions still work after IdP logout - IdP and SP sessions remain independent. Pass only when end-to-end behavior meets approved clinical-risk requirements. Record failures, compensating controls, owners, deadlines, and retest criteria.[4][5][8]
Tag failed or excessive access paths for role-claim and PHI-log review.
Review Role Claims and PHI Access Logs
Check Claims Against Clinical Roles
Use the authenticated identity from the prior checks to verify authorization and PHI access.
☐ IAM, application owners, and HR: Validate role claims against HR, credentialing, and application records. The SAML assertion proves identity; the service provider must authorize PHI access separately. Test at least one allowed and one denied action for each approved role. Check roles, departments, locations, employment status, specialty, and application permissions. Record the assertion subject, mapped application account, evaluated claims, resulting role, authorization decision, and PHI access outcome.[2][17][20] Use the results to confirm that each role has the correct PHI permissions and audit trail.
Claim-to-Clinical-Role Mapping
| Claim | Source system | Approved values | Application role | PHI scope | Conflict trigger |
|---|---|---|---|---|---|
| Department | HR | Approved department identifiers | Department-specific clinician or staff | Approved department records and functions | Department mismatch |
| Specialty | Credentialing | Approved specialty codes | Specialty privilege set | Approved specialty records and orders | Specialty or privilege mismatch |
| Employment status | HR | Active, approved contingent worker; terminated is ineligible | Active user or no access | Eligible users only | Ineligible status |
| Location | HR or approved directory | Approved facility or site codes | Site-specific role | Approved site records and workflows | Site mismatch |
| Privileged approval | Approval record | Approved authorization identifier and expiration | Elevated administrator or auditor | Explicitly approved administrative functions | Missing or expired approval |
Shared conflict rule: Deny access or assign the least-privileged approved role.
☐ Test missing, blank, unexpected, duplicated, expired, and conflicting claims. Also test case sensitivity, nested groups, and privileged claims without approval. Use hires, department or location transfers, leave events, credential changes, departures, and approval expiration or revocation to trigger mapping reviews, deprovisioning tests, and session invalidation checks. Cover every application, including cached permissions.
SAML does not deprovision application accounts. Record the separate account-removal event, completion time, exceptions, and evidence of session or token invalidation. Identify the system owner. Pass only when permissions and removal meet approved requirements.[20][22]
Link and Protect PHI Access Logs
Once role decisions are validated, trace the resulting PHI activity through application, IdP, and SIEM logs. Confirm that it matches the approved permissions.
☐ Security operations, privacy, and application owners: Link IdP authentication, SP authorization, and PHI activity using immutable workforce, application, event, and session IDs. Verify clock synchronization. Normalize timestamps to UTC, then report them in local U.S. time with the offset. Define an acceptable correlation window and record available device, source IP, workstation, and location context. Apply HIPAA audit controls to every system that stores or uses ePHI - not just the IdP.[10][16][18]
Required Log Event Table
| Event type | Minimum review fields beyond identity, application, and timestamp |
|---|---|
| Authentication | IdP, success or failure, MFA result, client context |
| MFA | Factor or policy result, success or failure, challenge context |
| Authorization | Asserted and effective role, requested function, decision, policy or claim basis |
| PHI access | Record or resource identifier, action, outcome, client context |
| Role change | Old and new role, source event, approver, effective time, deprovisioning result |
| Administrative action | Administrator, target account or role, action, approval, outcome |
| Certificate or trust event | Certificate or metadata identifier, action, actor, effective time, result |
| System and logging events | Time synchronization failure, collection interruption, tampering alert, retention or deletion action |
☐ Run a controlled test in each application. Cover authentication, MFA, allowed and denied actions, test-record access, administrative changes, and user revocation. Compare application, IdP, and SIEM records for exportability, event order, missing events, ingestion delays, and unmonitored access paths, such as direct local accounts.
Restrict log modification, protect log integrity, and monitor collection failures. Record the last successful ingestion and the outage-recovery process. Do not log raw assertions, secrets, clinical notes, or unnecessary PHI. Pass only when protected records identify the user, application, resource, action, context, and outcome.[10][18][19]
☐ Validate retention and deletion controls within the same audit trail. Set retention with privacy, legal, security, and records-management owners based on operating needs and legal review. Do not apply one universal six-year rule to every technical log. Before sign-off, document applicable state law, contracts, business-associate obligations, litigation holds, secure deletion, backup copies, exceptions, and remediation owners.[10][21][23]
Test Emergency Access and Review Vendors
Test Break-Glass Access and Downtime Recovery
Use the role and log findings above to test only approved exception-access paths.
☐ Clinical operations, IAM, security, application owners, and the help desk: Run controlled exception-access drills for an IdP outage, network disruption, and urgent-care access. For each application, record emergency-specific dependencies, allowed functions, recovery time, and rollback steps. Keep downtime recovery separate from emergency access: restoring one must not enable the other. HIPAA requires procedures to obtain necessary ePHI during an emergency - not an unrestricted sign-in bypass.[3]
☐ Require a named user, a recorded patient-care reason, approved scope, expiration or revocation, and monitoring. Verify that unavailable dependencies won't block the alternate workflow. Pass only when access is named, time-limited, monitored, and reviewed. Record access start and end times, authorization decisions, alerts, and the reviewer's disposition. After restoration, reconcile emergency activity with clinical records and security logs. Remove temporary privileges, rotate temporary credentials, and assign unresolved findings.
Review Vendor Controls and PHI Agreements
After validating emergency access, Review vendors that can affect SAML, support, or PHI handling using a guide to HIPAA-compliant vendor risk management.
☐ Security, privacy, legal, and application owners: Review current configuration records, test summaries, incident reports, and executed contracts. Verify assertion-validation duties, claims ownership, time-bound vendor support access, outage escalation, and applicable business associate agreements (BAAs). Check subcontractor obligations and test notification contacts. Business associates must report unsecured PHI breaches without unreasonable delay and within 60 days of discovery.[24]
Third-Party SAML Review Matrix
Keep one record per vendor–application connection:
| Required fields | Evidence and decision to record |
|---|---|
| Vendor, application, PHI exposure | Legal entity, product, environment, clinical function, and PHI handled |
| SAML owner and metadata source | Responsible contact, authoritative metadata location, assertion-validation duties, MFA enforcement, approved claims, and test results |
| Certificate control | Responsible contact, signing certificate expiration, rotation notice, overlap test, and rollback plan |
| Emergency access | Approved scope, expiration, monitoring, and last exception-access drill |
| Logging and outage support | Log exportability, support contacts, response commitments, and evidence-request process |
| PHI agreements | BAA, relevant subcontractor obligations, notification deadlines, audit rights, and PHI return/deletion terms |
| Review date and residual risk | Last assessment, open findings, remediation owner, next review trigger, and approval status |
☐ Pass only when requirements are met. Record accepted residual risk separately from control failures. Reassess after certificate or IdP changes, new subcontractors, changed PHI flows, privileged-access workflow changes, material incidents, or failed recovery drills. Verify that vendor access ends when approved support work ends.
Coordinate Risk Reviews with Censinet RiskOps
Use the completed vendor record to route findings, remediation, and sign-off into risk review.
☐ Use Censinet RiskOps™ to track vendor risk reviews, evidence, findings, remediation owners, risk decisions, and approval status.
Conclusion: Approve Results and Schedule Reviews
Assign Remediation and Sign Off
Use verified evidence from the prior checks to assign each finding a final disposition and obtain sign-off.
Security leadership and control owners: Confirm that every finding links to signed, dated evidence, including metadata, certificates, assertions, role mappings, logs, and break-glass tests.[25][26][27][28][29] Verify signed BAAs, documented security responsibilities, and completed risk analyses for every in-scope IdP and SSO vendor.[25][26]
Rank findings by patient-safety impact, PHI exposure, exploitability, sign-in risk, and downtime risk. Give each finding an owner, deadline, compensating controls, and disposition. Route approval to IT security, clinical informatics, nursing leadership, HR, legal, and the EHR integration team.[26]
Apply the result labels consistently:
- Pass: All requirements are met.
- Pass with Exceptions: Risks are approved and time-bound, with tracked remediation.
- Fail: Neither approval condition is met.[26]
Once disposition is assigned, lock the tested configuration into the audit record and schedule follow-up testing.
Schedule Retests and Record Audit Status
IAM and the audit coordinator: Store configuration snapshots and test evidence in a controlled repository. Schedule monthly deprovisioning reconciliations, quarterly log-export tests, and certificate reminders 60 days before expiration. Retest after any IdP or SP configuration change, metadata refresh, or certificate rotation.[25][26][29][30]
Use UTC or an explicit time-zone offset for timestamps. Tie the status block to the tested configuration, not just the sign-off date.[26][27]
Audit-status block - complete before approval
| Field | Record |
|---|---|
| Overall result | Pass, Pass with Exceptions, or Fail; approver and decision date |
| Applications reviewed | Application names and supporting evidence |
| Critical findings and open remediation | Finding IDs, owners, deadlines, and exception expiration dates |
| Emergency-access test | Last test date, outcome, and evidence link |
| Certificate risks | Expiration dates, rotation readiness, and unresolved risks |
| PHI logs | Timestamps in UTC or with an explicit time-zone offset, unique user identifiers, source IPs, device IDs, MFA event results, and retrieval-test result |
| Third-party review status | Signed BAAs, completed risk analyses, documented security responsibilities, and unresolved vendor findings |
| Next review | Scheduled date and change-triggered retests |
FAQs
How should we prioritize SAML audit failures?
Map each failure to a standardized inventory of applications that process ePHI [1]. Score findings based on data sensitivity, access scope, and security maturity [2].
Address critical gaps immediately, including missing MFA, weak static or shared credentials, missing centralized audit trails, and unlogged privileged sessions [1][3]. Close high-risk findings - including missing MFA for EMR access - within 24–72 hours. If an active compromise is underway, revoke access within 2 hours [3].
How can we test PHI access without real patient data?
Keep non-production environments strictly separate from production systems by using different accounts, subscriptions, or projects [1]. Use synthetic test accounts and dummy data to check configurations, role-based access control (RBAC), and authentication flows, including SAML integrations [2].
Verify that audit logs correctly record access attempts and policy enforcement, without exposing actual electronic protected health information (ePHI) during testing [1][2].
What if a clinical app cannot revoke active sessions?
Sessions left active on shared workstations put patient safety and HIPAA compliance at risk: staff may enter documentation or orders under the wrong identity [1]. Apply consistent session policies, use short-lived tokens with silent refresh, and ensure sessions don’t stay active on shared devices [1].
For critical security incidents, disable the account immediately and rotate shared secrets or service credentials. Then review access logs in your SIEM to support breach analysis [2][3].
