Back to Blog
ComplianceCompliance
November 2, 202612 min readBySiegePal LLC

HIPAA Compliance Requirements: What the Senate Cybersecurity Bill Would Change

On September 30, 2026, the Senate passed S. 3315, the Health Care Cybersecurity and Resiliency Act, by unanimous consent. Its most consequential provision directs HHS to rewrite core HIPAA compliance requirements around named security controls. Multifactor authentication, PHI encryption, and monitoring backed by penetration testing would become stated minimums. The current Security Rule already imposes enforceable requirements, including risk analysis, audit controls, and identity verification. It does not prescribe MFA, however, and it treats encryption as addressable.

None of this is binding yet. The House received the bill on October 5 and has not acted on it. Until Congress enacts a law and HHS writes implementing rules, the existing HIPAA Security Rule remains the enforceable standard. OCR is still investigating and settling cases under that rule. This article separates current obligations from proposed ones, then shows where cloud-native healthcare teams are most exposed.

What Is Mandatory Today, What Passed, and What Is Still Proposed

Three regulatory tracks are moving at once, and they blur easily in planning conversations. Only the first creates obligations OCR can enforce today.

TrackStatus on November 2, 2026Enforceable?
HIPAA Security Rule, 45 CFR Part 164, Subpart CIn force since 2003, last amended in 2013Yes
S. 3315Passed the Senate September 30; held at the House desk since October 5No
Proposed Security Rule update, RIN 0945-AA22Proposed January 6, 2025; listed as a long-term action, final action July 2027No

The bill and the proposed rule overlap in substance but differ in force. A statute would compel HHS to act on a fixed timeline. The proposed rule moves only as agency priorities allow. If both advance, HHS would probably need to reconcile them, though it has announced no such plan.

What Section 8 of S. 3315 Would Require

Four Practice Categories, No Configurations

Section 8 directs HHS to update the Security Rule so regulated entities adopt "minimum risk-based cybersecurity practices." The engrossed Senate text names four categories. The first two are multifactor authentication and encryption of protected health information. Both carry the qualifier "or a successor technology," which leaves room for methods that do not exist yet. The third covers monitoring requirements, explicitly including penetration testing. The fourth reaches other minimum standards reflected in national cybersecurity frameworks.

What the bill leaves out matters just as much. It names no MFA factor types, cipher suites, key management models, or testing frequencies. Those parameters would come from HHS rulemaking, which is where most engineering decisions would eventually be settled.

The Frameworks HHS Would Draw From

The practices must rest on named reference frameworks. Three NIST publications anchor the list: the Risk Management Framework, the Cybersecurity Framework, and SP 800-53 Rev. 5. The NIST AI Risk Management Framework appears as well. So do sector performance goals from the Health Sector Coordinating Council and CISA.

Teams shipping clinical or administrative AI features should note that AI framework reference. It creates a path toward control expectations for model pipelines that process PHI. The bill itself sets no AI-specific requirement, so how far HHS would take the reference remains an open question.

The 36-Month Clock and Enforcement Discretion

New requirements would take effect 36 months after enactment, and HHS could exercise enforcement discretion for entities facing extraordinary circumstances. Three years sounds generous until the work is scoped. Retrofitting encryption onto a legacy data store can involve schema changes, key hierarchy design, and planned downtime. Extending MFA to clinicians, contractors, and partner integrations usually takes far longer than securing engineering accounts. The clock also starts only at enactment, which has not happened. Until then, the window is planning time, not slack.

Who Would Be Covered

Section 8 applies to covered entities and business associates, the population HIPAA already regulates. It also names non-governmental entities in the Healthcare and Public Health Sector, defined by reference to National Security Memorandum 22. On its face, that wording could reach some health technology companies outside today's HIPAA perimeter. The bill does not explain how HHS would apply it.

Scope could also change before enactment. According to CHIME's bill summary, a House discussion draft would exclude medical devices from Section 8's minimum standards.

How These HIPAA Compliance Requirements Differ From the Current Security Rule

What "Addressable" Means Today

The current rule labels each implementation specification as either required or addressable, and addressable does not mean optional. Under 45 CFR 164.306(d)(3), an entity must assess whether the specification is reasonable and appropriate in its environment. If it is, the entity implements it. If it is not, the entity documents why and implements an equivalent alternative where reasonable.

Encryption at rest and encryption in transmission are both addressable today. Many organizations recorded exceptions years ago, often for systems since rebuilt, and never reopened them. For the controls it names, Section 8 would sharply narrow that flexibility.

Control-by-Control Comparison

Control areaCurrent Security Rule (enforceable)S. 3315, Section 8 (not law)
EncryptionAddressable at §164.312(a)(2)(iv) and §164.312(e)(2)(ii)Encryption of PHI, or a successor technology
Authentication§164.312(d) requires identity verification but names no methodMFA, or a successor technology
MonitoringAudit controls at §164.312(b); activity review at §164.308(a)(1)(ii)(D)Monitoring requirements, including penetration testing
TestingPeriodic technical evaluation at §164.308(a)(8); no named penetration testPenetration testing named explicitly

Fixed cadences, such as annual penetration testing, come from the proposed rule rather than the bill. Our guide to choosing a HIPAA compliance consultant covers that proposal in detail.

Monitoring Is Already Being Enforced

Monitoring is the category where current enforcement is most visible. On October 29, 2026, OCR announced an $800,000 ransomware settlement with Lehigh Valley Health Network. Its findings included a failure to regularly review information system activity records, such as audit logs and access reports. That review duty comes from today's Security Rule, not from the bill. A team that treats monitoring as a future requirement has misjudged its current exposure. Section 8 would add penetration testing on top of review obligations that already bind every regulated entity.

Why the Recognized Security Practices Provision May Matter Sooner

Section 7 could produce effects well before Section 8 does. It directs HHS to issue regulations within one year of enactment. Those regulations would implement the recognized security practices provision added to the HITECH Act in 2021. Under Public Law 116-321, OCR must consider whether an entity can demonstrate certain security practices. Those practices must have been in place for at least the previous 12 months. Section 7 would spell out how OCR weighs them when setting fines, ending audits early, and negotiating remedies.

The engineering consequence is easy to miss. Evidence must show controls operating across a full year, not on the day an investigator asks. A screenshot of an MFA policy proves far less than twelve months of authentication logs.

Hypothetical Example: Testing a Healthcare SaaS Stack Against Section 8

This scenario is illustrative. It does not describe a SiegePal client, engagement, or test result.

The Environment

Consider a Series B telehealth platform running on AWS. Clinicians sign in through an identity provider that enforces MFA. Patient records live in Amazon RDS for PostgreSQL with storage encryption enabled. A data team exports nightly extracts to an Amazon S3 bucket for analytics. On paper, the platform already touches all four Section 8 categories. The gaps appear only when someone tests access paths instead of reading the policies that describe them.

Checking Authentication Paths

A sensible starting point is any identity that bypasses the identity provider. Legacy IAM users with console passwords are the usual example. The AWS IAM credential report shows whether each of those users has an active MFA device.

# Hypothetical check: IAM users with a console password but no MFA device
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text \
  | base64 --decode \
  | awk -F, 'NR>1 && tolower($4)=="true" && tolower($8)=="false" {print $1}'

The check is useful but narrow. It ignores federated users, database accounts, and service-specific credentials. It also says nothing about the API keys integrations use to reach PHI. Any of those paths can touch patient data without an MFA prompt. Treat the report as a starting inventory, not proof of coverage.

Encryption and Monitoring Gaps

Storage encryption on RDS does not follow the nightly extract. The S3 bucket most likely relies on SSE-S3, which AWS applies to new objects by default. That satisfies a literal encryption check, yet it adds no separate decryption control. S3 decrypts transparently for any authorized reader.

Switching to SSE-KMS with a customer-managed key in AWS KMS adds a key policy and auditable key use. Monitoring has a parallel gap, because CloudTrail does not log S3 data events by default. Without those events, nobody can show who read the extract.

What Engineering Teams Should Do Before the House Acts

The steps below are engineering recommendations, not legal requirements. S. 3315 is not law, but each step also strengthens your position under the current Security Rule.

Reopen Every Addressable Exception

Pull every documented decision not to implement encryption or strong authentication, and check whether the original reasoning still matches production. Exceptions written for older architectures often describe environments that no longer exist. Where an exception remains justified, confirm that the equivalent alternative exists and works. Where it does not, schedule remediation now rather than waiting for a deadline.

Map Each Control to Evidence, Not Policy

For each Section 8 category, name the system that produces proof. MFA evidence comes from identity provider logs and cloud credential reports. Encryption evidence comes from key policies and configuration state captured continuously. Monitoring evidence comes from review tickets, handled alerts, and penetration test reports with retest results. Keep at least a rolling year of that operating evidence, which matches the recognized security practices look-back.

Bring Non-Human Access Into Scope

Service accounts, partner APIs, and data pipelines often sit outside MFA programs. Inventory every non-human path to PHI, including model training and inference pipelines. Where interactive MFA is impossible, decide which compensating controls apply, such as workload identity and short-lived credentials. The bill's "successor technology" language may accommodate such designs, but that is not guaranteed until HHS writes the rule.

Track the House Version

House changes to scope deserve close attention, especially the reported medical device exclusion and any change to effective dates. Assign an owner to monitor the bill's Congress.gov record and OCR announcements, and revisit the remediation roadmap whenever either moves.

What the Bill Does Not Settle

Several questions stay open until HHS writes regulations. The bill does not define acceptable MFA methods or exceptions. It does not say which data states encryption must cover, or what qualifies as a successor technology. It sets no penetration testing frequency, scope, or tester qualifications, and its coverage of non-HIPAA health entities needs interpretation. The House may still amend the text before it reaches the President. Planning around the named control categories is sensible, while planning around specific technical parameters would be premature.

Frequently Asked Questions

Does HIPAA require multifactor authentication today?

Not by name. The current rule at §164.312(d) requires procedures to verify that anyone accessing ePHI is who they claim to be. It does not prescribe a method. MFA is often the most defensible way to meet that standard. S. 3315 would make it an explicit requirement.

Would the bill change HIPAA breach notification letters?

Yes, in one specific way. Section 6 would amend the HITECH Act so that breach notices to individuals state the number of people affected. That change, like the rest of the bill, applies only if S. 3315 becomes law.

Key Takeaways

  • Today's HIPAA compliance requirements come from the current Security Rule, which OCR actively enforces.
  • S. 3315 would make MFA, PHI encryption, and monitoring with penetration testing named minimums 36 months after enactment.
  • Addressable exceptions for encryption and authentication are the most likely casualties of either the bill or the proposed rule.
  • The recognized security practices rulemaking could reward a year of operating evidence well before Section 8 applies.

How SiegePal Helps

SiegePal works at the infrastructure layer of HIPAA programs. We test whether MFA, encryption, and logging controls hold across real access paths. Our HIPAA compliance services map current Security Rule obligations to your cloud environment. Penetration testing validates exposure across web, API, and cloud infrastructure. Cloud security engineering closes gaps in identity, key management, and logging architecture. Security monitoring turns raw audit logs into reviewed activity.

We are an engineering and remediation partner, not a certification body, and no engagement guarantees compliance. To see where your environment stands, schedule a consultation with our team.

Sources Used

Legislative and regulatory status was checked against official records on November 2, 2026.