Search for this question and you will find sources that flatly contradict each other. Some say Firebase is HIPAA compliant. Others say it is not. Both are answering a slightly wrong question.
A Business Associate Agreement does not cover a brand. It covers a list of products, and that list is published on Google Cloud’s HIPAA compliance page, which was last updated on 2026-10-26 when I read it. What follows is how I read that list for a health product built on Firebase, and what I do about the gaps. It is not legal advice, and it is a snapshot: confirm against the live page before you build on it.
What was on the list
As of that page:
- Cloud Firestore is listed.
- Cloud Storage is listed, which is what Cloud Storage for Firebase sits on.
- Identity Platform is listed, with restrictions.
- Cloud Run functions is listed. Cloud Functions is not named separately, and the page does not say how the two map, so I confirm that in writing for the project in question rather than assuming.
And what I did not find on it: Firebase Hosting, Crashlytics, Google Analytics for Firebase, and Cloud Messaging. Firebase Authentication is not named either, only Identity Platform. The page does not say they are the same thing. For a project that depends on the answer, ask Google, and keep the reply.
The restrictions are the real content
Being on the list is the start. The page attaches conditions, and most real violations come from the conditions rather than the list.
For Identity Platform: store only the minimum data, keep PHI out of optional or custom attributes, do not transmit PHI from federated identity providers, do not synchronize PHI from external identity systems, do not use anonymous accounts, and do not use the Identity Platform SDKs or client libraries with PHI.
For Firestore: encrypt PHI or other sensitive data before using it as an entity key, an indexed property key, or an indexed property value. A patient’s email address as a document ID is the classic mistake, because IDs show up in logs, URLs, and indexes.
Across the board: disable services that are not covered when you work with PHI, avoid pre-GA features with PHI, and keep PHI and credentials out of resource metadata, where logs may capture them.
What I do with this
- Draw the PHI boundary first. List every service that will ever see PHI and every service that will not. The uncovered services go on the “never” side by design, not by discipline.
- Keep identifiers out of everything uncovered. Analytics, crash reports, and push payloads get opaque IDs only. If a screen shows PHI, treat what it logs the same way.
- Put the identity decision in writing. Which authentication product, which project, and what Google confirmed.
- Date the evidence. Save the covered-products page as it read when you decided. The list can change without anyone signing anything, so a dated copy is what you show a reviewer.
- Test the boundary. Write down what a crash report, a push notification, and a failed request each contain, then check it against real output.
None of this is exotic. It is the same discipline as an audit trail that can answer a question or role-based access that holds up: decide where PHI may live, then make everywhere else incapable of holding it.
The full set of decisions, in the order they have to be made, is in the HIPAA architecture checklist. If you are still choosing a stack, sending PHI to LLM APIs covers the other big vendor boundary.