What "authenticated" means
A page is authenticated when the visitor has logged in with a username and password (or a similar credential). The website knows who they are. They have an account, a session token, or both.
A page is unauthenticated when anyone can reach it without logging in. The website doesn't know who the visitor is. It might know an IP address and a browser fingerprint, but not a name.
The login page itself — the screen where you enter your username and password — is unauthenticated. Anything past that point, where you can see your appointments, lab results, messages, or bills, is authenticated.
Why the distinction matters legally
The OCR Tracking Technologies Bulletin treats authenticated and unauthenticated pages differently.
On authenticated pages, OCR's position is straightforward. The covered entity knows who the patient is. The patient is logged into a healthcare context. Anything the website learns about that patient's behavior — pages viewed, appointments scheduled, results checked — is health information about an identified person. That's PHI. Sharing it with a third party without a BAA and without authorization violates HIPAA.
On unauthenticated pages, the analysis is harder. The visitor's identity isn't established. OCR's original position was that an IP address plus a healthcare context was enough to count as PHI. AHA v. Becerra vacated that for ambiguous-intent pages.
Authenticated pages were not part of the carve-out. That part of the bulletin still applies. So do all of the class actions built around authenticated-page disclosures.
Why it's easy to mess up
Three traps.
The first is the login-page trap. The login page itself is unauthenticated, but the scripts loaded on the login page often persist after login. So a tracker installed "just on the login page for marketing analytics" actually fires on every authenticated page after that. Most hospital marketing teams don't realize this.
The second is the marketing-pixel-on-portal-subdomain trap. Patient portals usually live on a separate subdomain — `mychart.yourhospital.org`, `portal.yourpractice.com`, `patient.yoursystem.org`. Marketing teams assume those subdomains are run by the IT or EHR team. IT and EHR teams assume marketing manages the trackers. Often nobody does, and the marketing-site trackers get duplicated onto the portal because someone copied a Tag Manager configuration.
The third is the mobile-app trap. Mobile apps are essentially always authenticated after the first login. Tracking SDKs in those apps see every screen the patient visits. Cerebral's $7M+ FTC settlement was largely a mobile-app SDK case. Most hospitals don't apply the same scrutiny to their app's tracking stack as they do to their website.
What to check on your own site
Three quick tests.
First, find your patient-portal login page. View source. Look for any third-party scripts: Meta Pixel, Google Analytics, Microsoft Clarity, Hotjar, Optimizely, anything you don't recognize. Anything there probably persists after login.
Second, ask your EHR vendor or portal vendor what tracking is enabled by default. The honest ones will give you a list. Some EHR vendors enable Google Analytics by default and don’t tell their customers.
Third, check your mobile app if you have one. There's a free service called Exodus Privacy that does static analysis of any Android app from Google Play and lists every embedded tracker SDK. It's the easiest way to see what's actually running.
What to do if you find trackers on authenticated pages
The same playbook as anywhere else, but with more urgency. Document the finding. Remove the tracker. Audit how it got there. Update your tag-management governance so it doesn’t happen again.
If the tracker has been there for a while, you may have a breach-notification obligation under 45 CFR §164.404. Talk to a healthcare attorney before deciding. The 60-day clock starts from the day you discovered it, not from the day the tracker first fired.