Ideally not by default. Give vendor support staff no standing access to production PHI, and grant time limited, logged access when a ticket needs it. The Security Rule addresses access authorisation, unique user identification, audit controls and termination procedures, which together point that way. Choose the model that fits your risk.
What the rule points toward
Access control requires unique user identification and an emergency access procedure, both required, plus automatic logoff and encryption as addressable. Information access management includes access authorisation and access establishment and modification, both addressable. Audit controls require mechanisms that record and examine activity in systems containing ePHI. Workforce security covers authorisation, supervision and termination procedures.
Four access models
| Model | How it works | Risk | Fit |
|---|---|---|---|
| Standing access | Support accounts always have production access | High: broad, always on | Hard to justify |
| Ticket approved access | Access granted per ticket, by the customer | Medium: approvals can be rubber stamped | Common middle ground |
| Time boxed break glass | Short, logged elevation for emergencies | Low to medium | Good for outages |
| No access with redacted tooling | Support sees masked data, screen shares with consent | Lower | Strong default for routine support |
Contract and review questions
- Who at the vendor can see our PHI, by role?
- Is access individual, with unique IDs, or through shared accounts?
- Can we approve or deny a session, and see the log afterwards?
- How long does access last, and how is it revoked?
- Is vendor staff access from approved devices with multi factor authentication?
- What happens to access when a vendor employee leaves?
Useful controls on your side
- Mask or tokenise fields by default in support views.
- Record screen sessions with consent where policy allows.
- Review a sample of vendor access logs each quarter. The rule expects procedures to regularly review records of information system activity.
- Alert on access outside the ticket window.
- Keep a list of vendor staff with approved access and refresh it.
Minimum necessary
The minimum necessary standard asks for reasonable efforts to limit PHI to what is needed for the purpose. For support, that means the one record, not the table.
A worked example
A clinic reports a failed appointment sync. The support engineer needs to see one patient record. Under standing access, they open the production console and browse. Under ticket approved access, the clinic approves a thirty minute window for that record, the session is logged, and access ends on its own. The second path takes a few extra minutes and leaves a trail you can review. Make that trail part of the contract, and test it once so you know the log is usable.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, reachability analysis, continuous monitoring and evidence automation that can support a vendor review. You can run a free scan at gold.safeguard.sh/scan. It does not make any organisation compliant with HIPAA, and this post is not legal advice.
Quick check
Is shared support login acceptable?
No for ePHI systems. Unique user identification is required, and shared logins break your audit trail.
What about emergencies?
Use a documented break glass path with approval, time limit and review afterwards.
Sources
Last reviewed: 19 October 2026.
