If your healthcare SaaS application stores, processes, or transmits electronic protected health information (ePHI), network security is part of your HIPAA responsibility. But HIPAA firewall requirements are frequently misunderstood — and that misunderstanding creates real compliance risk.
The HIPAA Security Rule (45 CFR Parts 160 and 164) does not prescribe a specific firewall vendor, firewall type, port list, or configuration. Instead, covered entities and business associates must assess risks to ePHI and implement reasonable and appropriate safeguards based on those risks. HHS specifically says organizations evaluating network connections should assess safeguards ranging from the firewall to the people authorized to access the data.
For SaaS companies, that distinction matters. Installing a firewall does not make an application HIPAA compliant. The firewall must be part of a broader security architecture that controls access, protects network traffic, records relevant activity, and responds to identified risks.
As Gil Vidals, CTO and co-founder of HIPAA Vault, explains about the risk-based approach to network security:
“HIPAA doesn’t hand you a shopping list of technologies. It hands you a responsibility — assess your risks and protect ePHI appropriately. For most internet-facing healthcare applications, that means a layered network security architecture. The firewall is one layer. The WAF is another. The monitoring, the access controls, the audit logging — they all work together. You can’t just check ‘firewall installed’ and call it done.”
Does your SaaS infrastructure have HIPAA security gaps? HIPAA Vault provides managed firewall, WAF, IDS/IPS, and 18 security controls — all included with a signed BAA.
Get a free security assessment →
- HIPAA does not prescribe a particular firewall product, vendor, or universal configuration
- The Security Rule requires organizations to protect ePHI and reduce identified risks to a reasonable and appropriate level
- HHS specifically identifies the firewall as one safeguard organizations may need to evaluate when securing network connections
- A firewall alone is not sufficient for HIPAA compliance — it’s one layer of a broader security architecture
- A WAF protects a different layer than network firewalls and should not be treated as a replacement
- The 2025 proposed Security Rule would introduce more explicit network security requirements — but those proposals are not currently in effect
- Security controls should follow your documented risk analysis, not a generic checklist copied from another organization
Does HIPAA Require a Firewall?
HIPAA does not contain a standalone requirement stating that every regulated organization must deploy a particular firewall.
Instead, the Security Rule is technology-neutral and risk-based.
Under 45 CFR § 164.306, covered entities and business associates must:
- Protect the confidentiality, integrity, and availability of ePHI
- Protect against reasonably anticipated threats
- Implement reasonable and appropriate safeguards
HHS makes clear that the Security Rule does not require organizations to purchase a particular technology. Security measures should reflect factors including the organization’s size and capabilities, technical infrastructure, cost, and the probability and criticality of risks to ePHI.
But that does not mean firewalls are irrelevant to HIPAA.
HHS specifically addresses network connections in its Security Rule guidance: organizations must evaluate the risks associated with network connections and establish safeguards that reasonably protect the information exchanged across the network — including consideration of the firewall.
For an internet-facing healthcare SaaS application, allowing unrestricted network access to systems containing ePHI would create an obvious risk that must be evaluated and appropriately mitigated.
The correct question isn’t: “Does HIPAA say I need a firewall?”
It’s: “What network risks threaten our ePHI, and what controls are reasonable and appropriate for reducing those risks?”
For most modern healthcare environments, firewall controls are part of that answer.
Which HIPAA Rules Apply to Firewalls?
There is no section of the Security Rule titled “Firewall Requirement.” Instead, firewall controls can support several HIPAA Security Rule requirements:
Security Management Process — 45 CFR § 164.308(a)(1) Organizations must implement policies and procedures to prevent, detect, contain, and correct security violations — including conducting a risk analysis and implementing security measures sufficient to reduce identified risks to a reasonable and appropriate level. Your firewall architecture should follow the risks identified in your HIPAA risk analysis, not a generic checklist.
Access Control — 45 CFR § 164.312(a)(1) The Security Rule requires technical policies and procedures that allow access to systems containing ePHI only to people or software programs that have been granted appropriate access rights. Network-level controls provide an additional enforcement layer — for example, a production database containing ePHI generally should not be directly reachable from the public internet merely because application-level authentication exists.
Audit Controls — 45 CFR § 164.312(b) Organizations must implement mechanisms that record and examine activity in systems that contain or use ePHI. Firewall, WAF, load-balancer, and cloud-network logs can contribute valuable evidence about attempted connections, blocked traffic, and suspicious behavior. Enabling firewall logs does not by itself satisfy the entire audit-controls requirement — application, identity, database, and infrastructure activity may also need to be logged.
Transmission Security — 45 CFR § 164.312(e)(1) HIPAA requires technical security measures to guard against unauthorized access to ePHI transmitted over electronic communications networks. Firewall rules can restrict where traffic is allowed to originate and terminate, but they do not replace encryption or other transmission-security controls.
Security Incident Procedures — 45 CFR § 164.308(a)(6) Regulated entities must have procedures to identify and respond to suspected or known security incidents. Firewall alerts can become one input into that incident-detection and response process.
HIPAA Firewall Requirements vs. Security Best Practices
A common compliance mistake is treating every cybersecurity best practice as though HIPAA explicitly mandates it. The distinction matters.
| Control | Current HIPAA Rule |
| Specific firewall brand | Not prescribed |
| Specific firewall appliance | Not prescribed |
| Universal port list | Not prescribed |
| Risk analysis | ✅ Required |
| Risk management | ✅ Required |
| Access controls | ✅ Required |
| Audit controls | ✅ Required |
| Transmission security | ✅ Required standard |
| Incident-response procedures | ✅ Required |
| Network segmentation | Risk-based today; explicitly proposed in 2025 NPRM |
| Vulnerability scanning every 6 months | Proposed — not current explicit frequency |
| Annual penetration testing | Proposed — not current explicit requirement |
HIPAA’s current approach gives organizations flexibility — but also responsibility. You cannot defend an insecure network simply by saying that HIPAA never specifically named the missing technology. HHS expects organizations to identify risks and select reasonable and appropriate security measures for their own environments.
NIST SP 800-66 Rev. 2 provides additional cybersecurity guidance for implementing the HIPAA Security Rule, developed in collaboration with HHS OCR to help regulated entities assess and manage risks to ePHI.
10 Firewall Controls Healthcare SaaS Teams Should Evaluate
These are not a universal HIPAA configuration template. Your final architecture should follow your documented risk analysis.
1. Default-Deny Inbound Traffic Start from the principle that network traffic should not be allowed simply because no one has blocked it. A healthcare SaaS production environment may need HTTPS traffic on port 443 while having no reason to expose database, cache, SSH, orchestration, or administrative services directly to the internet.
2. Restrict Administrative Access Administrative interfaces represent high-value targets. Restrict access using VPN or zero-trust access, IP restrictions, identity-aware proxies, MFA, privileged-access controls, and bastion or controlled administrative access patterns. Do not expose administrative services publicly without a documented reason and appropriate safeguards.
3. Keep Databases Off the Public Internet An ePHI database generally should not need direct inbound internet access. Place databases on private networks and restrict network access to only the applications and administrators that require it. A database password is not a substitute for network isolation.
4. Control Outbound Traffic A compromised application that can communicate freely with any internet destination may make data exfiltration easier. Evaluate whether production workloads actually require unrestricted outbound connectivity and restrict destinations where reasonable and appropriate.
5. Segment Systems by Trust Level Avoid putting every workload into one flat network. Consider separating internet-facing applications, APIs, application services, databases, administrative systems, development environments, production environments, and monitoring infrastructure. Segmentation reduces the blast radius when one component is compromised.
6. Use a WAF for Internet-Facing Web Applications A web application firewall can inspect HTTP/HTTPS traffic and help detect or block SQL injection, cross-site scripting, malicious request patterns, automated scanning, and exploit attempts. A WAF should complement — not replace — network access controls.
7. Log Firewall Activity Collect security-relevant firewall and network events — blocked connection attempts, administrative changes, rule modifications, unusual source addresses, repeated denied traffic, anomalous outbound connections, and WAF rule triggers. Logs are useful only if your organization has a process for reviewing and acting on them.
8. Review Firewall Rules Regularly Cloud environments change rapidly. Review rules for obsolete services, overly broad CIDR ranges, unrestricted 0.0.0.0/0 access, unnecessary administrative ports, stale vendor access, temporary exceptions, and abandoned infrastructure. Tie changes to documented change-management procedures.
9. Protect Firewall Administration Restrict who can create, delete, or modify rules, disable logging, alter WAF policies, or change security groups. Use individual accounts rather than shared administrator credentials and log all administrative changes.
10. Test Whether the Controls Actually Work A firewall rule that looks correct in a console may still leave a service reachable through another path. Use vulnerability scanning and, where appropriate, penetration testing to validate your exposure. HIPAA Vault provides HIPAA penetration testing for healthcare environments.
Is a WAF Enough for HIPAA Compliance?
No. A web application firewall alone does not make an application HIPAA compliant.
A WAF primarily protects web application traffic per OWASP Top 10 threat categories. A complete SaaS security architecture involves several different control layers:
| Control | Primary Purpose |
| Network firewall / cloud firewall | Controls network connections |
| WAF | Filters HTTP/HTTPS application traffic |
| Security groups | Restrict workload-level network access |
| IAM | Controls identities and permissions |
| Application authorization | Controls what authenticated users can do |
| Encryption | Protects data at rest and in transit |
| Audit logging | Records security-relevant activity |
| IDS/IPS or threat detection | Detects or blocks suspicious behavior |
HIPAA compliance depends on the system as a whole — not whether one security product has been installed.
As Gil Vidals explains about the layered approach HIPAA Vault takes for every client:
“When we deploy a healthcare environment, we’re thinking about every layer simultaneously. Firewall rules, WAF, IDS, audit logging, encryption, access controls — they all have to work together. A gap in any one of them can expose ePHI regardless of how strong the others are. That’s why managed security exists — most healthcare organizations can’t maintain all of that in-house.”
HIPAA Firewall Requirements for Cloud and SaaS Applications
Cloud architecture changes what a “firewall” looks like — you may not have a physical firewall appliance at all. Instead, controls may include:
- AWS: Security groups, network ACLs, AWS WAF, load-balancer controls
- Google Cloud: VPC firewall rules, Cloud Armor, IAM, private networking
- Azure: Network Security Groups, Azure Firewall, Web Application Firewall, private networking
A SaaS company can implement strong network protections entirely through software-defined cloud controls. The HIPAA question remains the same: does the architecture reasonably and appropriately protect ePHI against the risks identified in your risk analysis?
The cloud provider’s security controls do not automatically make your application compliant. See AWS HIPAA compliance for the shared responsibility model. Responsibility remains divided between the provider and customer — and business-associate relationships must be addressed where applicable.
HIPAA Penetration Testing—Go Beyond Automated Scans
Validate your security with an objective, third-party audit. We simulate real cyberattacks to uncover vulnerabilities and provide a comprehensive compliance report.
Learn MoreWhat the Proposed HIPAA Security Rule Could Change
⚠️ Important: The following changes are proposed and not currently in effect. The existing HIPAA Security Rule remains in effect unless and until HHS finalizes new requirements and applicable compliance dates arrive.
HHS’s January 2025 proposed Security Rule update would make network-security expectations considerably more explicit. Among other changes, the proposal would require:
- Technology asset inventory and network map
- Network segmentation
- Disabling extraneous network ports according to the organization’s risk analysis
- Vulnerability scanning at least every six months
- Penetration testing at least once every 12 months
- Multi-factor authentication, with limited exceptions
For SaaS teams, the direction is clear even though these provisions remain proposed: HHS is placing increasing emphasis on demonstrable, testable cybersecurity controls rather than informal assumptions that a network is secure.
HIPAA Firewall Checklist for SaaS Teams
Use this as a starting point — not a substitute for a HIPAA risk analysis.
| Question | |
| ☐ | Have we identified every system that creates, receives, maintains, or transmits ePHI? |
| ☐ | Have we documented the network paths between those systems? |
| ☐ | Are only necessary internet-facing services exposed? |
| ☐ | Are databases containing ePHI isolated from unnecessary public access? |
| ☐ | Are administrative interfaces appropriately restricted? |
| ☐ | Do firewall rules follow least-privilege principles? |
| ☐ | Are production and development environments appropriately separated? |
| ☐ | Have we evaluated outbound network access? |
| ☐ | Is a WAF protecting relevant internet-facing applications? |
| ☐ | Are firewall and WAF events logged? |
| ☐ | Are security-relevant logs actually reviewed or monitored? |
| ☐ | Are firewall configuration changes attributable to individual administrators? |
| ☐ | Are stale and temporary firewall rules periodically removed? |
| ☐ | Have we assessed third-party and vendor network access? |
| ☐ | Have we tested externally reachable systems for unexpected exposure? |
| ☐ | Are network risks documented in our HIPAA risk analysis? |
| ☐ | Do identified vulnerabilities have owners and remediation plans? |
Frequently Asked Questions
This article is educational and does not constitute legal advice. Security controls should be selected based on your organization’s risk analysis, architecture, regulatory obligations, and documented security program.
