The Technology Didn't Change. The Risk Did.

The computer still turns on.

The browser still opens. The firewall still passes traffic. The application your office has used for years still does exactly what it did yesterday.

And it may no longer carry the same security risk it did yesterday.

A vendor ends support. A vulnerability is disclosed. A vulnerability that sat quietly for years starts being used in real attacks. A vendor publishes a critical advisory. A release everyone stopped thinking about becomes worth looking at again.

Nothing inside the practice changed. The risk did.

Is outdated software a HIPAA violation?

Not automatically.

HIPAA maintains no list of forbidden operating systems, browsers, firewalls or applications. What the Security Rule requires is an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity and availability of ePHI, and security measures sufficient to reduce identified risks to a reasonable and appropriate level.

That provision names no particular technology. Its scope is set by what actually threatens patient information, which is why a vulnerability introduced by unpatched, unsupported or obsolete software sits inside it. HHS OCR has treated it that way consistently — a 2018 newsletter on patch management, an enforcement bulletin tying a settlement to unpatched and unsupported software, and a January 2026 newsletter on system hardening that restates risk analysis as something which must surface unpatched-software exposure and pair it with remediation.

So the honest formulation is narrower than "old software is a violation" and more demanding than "we are fine because it still works":

Unsupported or vulnerable technology is something a practice needs to know about, evaluate, and address reasonably. Discovering it after an incident is the outcome the rule is trying to prevent.

An inventory is not intelligence

Most practices can eventually answer what do we use?

An inventory is a list of what you own. It is a snapshot, taken once, of decisions already made. It does not tell you what has happened to any of those things since you bought them.

Knowing the office has a firewall is not the same as knowing that the firewall's vendor published a critical advisory eleven months ago.

That second question — what do we currently know about the things we use? — is a different kind of question, and it has a different shape. It has no final answer. It changes without anyone touching anything.

That is the gap The Naughty List exists to close. It is a free lookup: name a technology, and Patient Protect tells you what it currently knows about it, with the evidence attached.

Why working technology becomes risky

Software has a life after installation. A practice buys a computer in 2023 and is still using it in 2027. Across those four years:

• the operating system can reach end of support
• new vulnerabilities can be discovered
• a previously quiet vulnerability can start being exploited
• a firewall or router vendor can issue a critical advisory
• the application can stop receiving security fixes

None of those events require anyone in the practice to do anything.

That is the uncomfortable part. Broken technology gets noticed. Quietly aging technology usually does not. A dead computer gets replaced. A slow workstation gets complained about. A firewall running a six-year-old release keeps passing traffic and gives nobody a reason to think about it.

The riskiest device in the office may be the one nobody has a reason to look at.

Recognition and risk are different things

This distinction matters more than it sounds, and it is where most tools quietly mislead people.

Patient Protect may recognize a product without having published a risk finding about it. Those are two separate statements:

Identified does not mean vulnerable. We can resolve "Dentrix G7" to a real product in our catalog and have no published finding for it. That is a normal, correct result.

No known risk identified does not mean safe. It means we did not identify a known risk within the security intelligence we currently cover for that product. It is a statement about our evidence, not a clean bill of health for the software.

Partial coverage means exactly what it sounds like. Some vendors publish detailed security advisories with affected versions and fixed releases. Others publish little that can be responsibly treated as a source of record. Coverage differs by product, and the result tells you which situation you are in.

Keeping those three ideas apart is the whole discipline. A tool that collapses them produces a more confident answer and a less true one.

What if Patient Protect finds nothing?

That answer matters as much as a warning does.

A technology can be recognized without having a published Patient Protect risk finding. That does not mean the product is safe. It means Patient Protect did not identify a known risk within the security intelligence currently available for that product.

Coverage varies. Some vendors publish detailed security advisories and fixed-version information. Others publish little or nothing that can responsibly be treated as a source of record.

We would rather tell you what we do not know than turn missing evidence into reassurance.

The source is part of the answer

Different sources can establish different things, and treating them as interchangeable is how a plausible answer becomes a wrong one.

CISA can establish that a vulnerability is being exploited. Its Known Exploited Vulnerabilities Catalog lists vulnerabilities with reliable evidence of active exploitation in the wild, and CISA recommends that all organizations — not only federal agencies — build addressing them into their vulnerability management.

A vendor or CNA can establish which versions are affected and which release fixes them. That is the evidence that turns "this product has a problem" into "your build is inside the affected range."

FIRST EPSS estimates the probability that a published vulnerability will be exploited in the next thirty days. It is useful supporting intelligence. It is not a statement that your installation is affected.

Patient Protect adds interpretation, healthcare relevance and severity where the evidence supports it.

Patient Protect keeps those claims attached to the sources that actually support them. Confirmed exploitation is not inferred from a probability score, and an affected-version range is not invented because a finding would look better with one.

How to check something in your practice

Start with the exact product and version. The more precisely a technology is identified, the more precisely it can be evaluated.

Instead of Chrome, use Google Chrome 142.0.7444.176. Instead of Fortinet firewall, use FortiOS 7.2.1. Instead of Windows, use Windows 10 Pro 22H2.

Version information usually lives under a product's About, System Information, Administration, Update or Device Information screen. If an IT provider manages the technology, ask them for the full product name and the installed release.

Then check it. The answer will be one of a small number of honest states: the finding applies to what you entered, it does not appear to apply to your version, we cannot tell yet, no known risk was identified within our coverage, or we could not identify the technology at all.

Those answers are deliberately different from one another. Precision matters more here than a dramatic result.

What to do if something is listed

Do not panic. Work through four questions.

Are we actually running it? Confirm the full product name and release rather than the general product family.

Does it touch ePHI, or something the practice depends on? A vulnerable system holding patient records is a different problem from an old utility on a disconnected workstation. If you do not already know where patient information moves, map that first — it changes which findings matter.

What does the authoritative source recommend? Depending on the finding, that may be an update, an upgrade to a supported release, a vendor mitigation, a configuration change, a documented extended-support arrangement, or replacement. Use the source evidence rather than inventing a fixed version from a headline.

Can you show what you did? Record what was identified, which system it affected, what information that system handles, the risk you evaluated, the decision you made, and the evidence that the work was completed. That record is the difference between knowing about a vulnerability and managing it.

Why not just search CVE databases?

Because a vulnerability database answers a different question.

A raw CVE record is written for security professionals. A dental or medical practice wants to know something narrower and more useful: does this matter to the technology sitting in my office? Answering that requires connecting several pieces of information that a CVE record does not contain on its own.

The Naughty List is deliberately not another CVE database. It is a curated technology-risk layer, and for every published finding Patient Protect keeps the evidence behind the material claims visible, so you can see why a finding exists rather than taking our word for it.

When CISA establishes known exploitation, we show that. When authoritative evidence establishes an affected version range, we distinguish it. When the evidence does not establish applicability, we say so. When our coverage is incomplete, we say that too.

The objective is not to make every piece of technology look dangerous. It is to make uncertainty visible.

Where this sits in a practice

Independent practices run an unusual amount of technology for their size: scheduling, clinical documentation, billing, imaging, prescribing, remote access, file storage, networking, backups. Much of it creates, receives, maintains or transmits patient information.

Very few of those practices have anyone watching vendor advisories and vulnerability feeds. The information exists and is public. The harder problem is making it useful to the person responsible for a twelve-person office.

Checking one technology is a good place to start. Understanding your environment is the next step: mapping where patient information actually moves shows which systems the answers apply to. Inside Patient Protect, practices maintain their information-systems inventory and manage the security and compliance work surrounding those systems.

The dangerous part of old or vulnerable technology is often not that it stops working. It is that it keeps working long enough for everyone to stop asking questions about it.