No — no Firebase-branded service is covered by Google's HIPAA BAA. The agreement is signed with Google Cloud and covers only the products named on its Covered Products list: Firestore, Cloud Storage, Cloud Run functions and Identity Platform are on it; Firebase Authentication, Realtime Database, Hosting, Crashlytics and Analytics for Firebase are not. Moving an existing app onto the covered services takes us 6–10 weeks.
| Fact | Value |
|---|---|
| Tool | Firebase |
| Verdict | No |
| Sources checked | August 2026 |
| Typical range | $13,000–$25,000 |
| Typical timeline | 6–10 weeks |
| Last updated | August 2026 |
Which services the BAA actually covers
"Covered" here means named on Google Cloud's Covered Products list — the list the Google Cloud Platform BAA points at to define its own scope. The agreement on record is the Google Cloud Platform BAA, and it defines its own scope by pointing at that list — where no Firebase-branded service is named. Coverage also depends on you having signed the BAA in the first place.
Your PHI
Your Firebase app
Inside the agreement — PHI may live here
- Firestore (under its Google Cloud name)
- Cloud Storage
- Cloud Run functions
- Identity Platform
Outside it — PHI here is a gap
- Firebase Authentication
- Firebase Realtime Database
- Firebase Hosting
- Google Analytics for Firebase
- Crashlytics
- Remote Config / A/B Testing
- Any Pre-GA product
| Service | Under the BAA | Condition |
|---|---|---|
| Firestore (under its Google Cloud name) | Covered | — |
| Cloud Storage | Covered | — |
| Cloud Run functions | Covered | — |
| Identity Platform | Covered | — |
| Firebase Authentication | Not covered | Google's own comparison table prints No in the BAA coverage row for this product, against Yes for Identity Platform. |
| Firebase Realtime Database | Not covered | — |
| Firebase Hosting | Not covered | — |
| Google Analytics for Firebase | Not covered | — |
| Crashlytics | Not covered | — |
| Remote Config / A/B Testing | Not covered | — |
| Any Pre-GA product | Not covered | — |
This table reflects the Covered Products page as we read it in August 2026; the page carried the stamp "Last updated 2026-08-11 UTC". Because the contract defines coverage by reference to that page, the scope can move without any contract being re-signed. Open the page yourself and check the exact product names before you rely on this table.
Why the service names you expect are the wrong ones
What secondary sources say
Our own draft of this page described the covered services as "Cloud Firestore" and "Cloud Functions" until we checked those strings against the list itself. They are the names most people expect to find, us included, which is why we are printing the correction rather than quietly fixing it.
- Our own pre-verification draft of this page, corrected on 25 August 2026 before publication.
What the vendor's own documentation says
On Google Cloud's Covered Products page the strings are "Firestore", "Cloud Storage", "Cloud Run functions" and "Identity Platform". "Cloud Firestore" appears zero times on that page, and "Cloud Functions" is not among the covered entries. No Firebase-branded service is named anywhere in the list.
How we resolve it
The exact names matter because the list is the definition of scope, not a description of it — the BAA text points at the page to say what "Covered Services" means. If you are checking your own stack, search for the exact strings above. Searching for "Cloud Firestore" returns nothing and reads like an absence of coverage where coverage exists; assuming "Firebase Firestore" is on the list reads like coverage where the brand name gives you none.
Where PHI actually ends up in a Firebase app
The Firebase Authentication user store
HighEmail addresses, phone numbers, display names and profile photos of every person who signs up live in the Firebase Auth user record — a service Google marks as having no BAA coverage. In a healthcare app, the fact that a named person is a user is itself information about that person.
How to check
Firebase console → Build → Authentication → Users. Scan the list for real people rather than test accounts. If real patients or clinicians are in there, your identity data sits outside the covered set.
Crashlytics crash reports, custom keys and breadcrumb logs
HighCrash reports carry whatever your code logged just before the crash: a record body, a patient identifier, an error string containing a name. That text is copied off the device into Crashlytics, which is not on the Covered Products list.
How to check
Firebase console → Crashlytics → open the most recent issue → read the Logs and Keys tabs. Read the actual values, not the field names.
Analytics events and their parameters
HighScreen names and custom event parameters are where clinical detail leaks quietly — an event parameter holding a condition, a medication, a procedure type or an appointment reason. Google Analytics for Firebase is not on the Covered Products list.
How to check
Firebase console → Analytics → Events. Open a custom event and read its parameter values. Also check whether your app initialises Analytics at all — if it does not, this surface is closed.
A Realtime Database instance sitting alongside Firestore
HighApps that store records in Firestore often keep presence, chat, queues or draft state in Realtime Database as well. Firestore is named on the covered list; Firebase Realtime Database is not, so the same data can be covered in one place and uncovered in the other.
How to check
Firebase console → Build → Realtime Database. If an instance exists, expand the root node and read what is stored under it.
Firebase Hosting releases and preview channels
MediumAnything you serve or stage — an exported report, a patient-facing page, a demo build seeded with a real export — is served by Firebase Hosting, which is not on the covered list. Preview channels are the usual culprit because they outlive the review they were created for.
How to check
Firebase console → Hosting → Release history and the preview channel list. Open any live preview URL and see whether real records load.
The chat history of the AI builder you built this with
MediumDuring the build it is normal to paste one real export row into the builder's chat to show the model the shape of the data. That copy stays in the builder vendor's history, which is outside the Google Cloud agreement entirely — a different vendor, a different contract, often no contract at all.
How to check
Open your builder's chat history and search it for a surname, an email domain or a record-number prefix you know is real.
Six checks you can run before you talk to anyone
Five of these are answerable from a dashboard in under a minute; the sixth is a question for whoever holds your contracts. Run them before you pay anybody — including us — because the answers decide whether there is a project here at all.
01In Firebase console → Authentication → Users, are there real patients or clinicians in the list (not test accounts)?
02Can someone at your company produce a signed Business Associate Agreement with Google Cloud today?
03In Firebase console → Crashlytics, open the newest issue: do the Logs or Keys tabs contain anything that identifies a person?
04In Firebase console → Realtime Database, does an instance exist with data under its root node?
05In Firebase console → Analytics → Events, does any custom event parameter contain a condition, a medication, a procedure or a person's name?
06In Firebase console → Hosting, is any preview channel URL still live and serving real data?
What we do about it
Typical range
$13,000–$25,000
Typical timeline
6–10 weeks
- 01
Service map
3–5 daysA one-page map of every Firebase and Google Cloud service your app touches, each marked covered or not covered against the Covered Products list, with the date we read that list printed on it.
- 02
Identity migration
2–3 weeksUser records moved from Firebase Authentication to Identity Platform, every sign-in and password-reset path re-pointed and tested, old records removed.
- 03
Data move onto covered services
1–2 weeksRealtime Database nodes and any uncovered storage moved into Firestore and Cloud Storage, with a written record of what moved, what was copied and what was deleted.
- 04
Telemetry cleanup
1–2 weeksAnalytics and Crashlytics either removed or reduced to events that carry no identifiers, with a before-and-after list of every event and parameter name.
- 05
Access and audit trail
1 weekProject access narrowed to named individuals, audit logging switched on for the covered services, and an exported sample showing who read which records.
- 06
Handover pack
3–5 daysA written document with the service map, the checks we ran, the dated source pages behind each decision, and an explicit list of what remains your responsibility — the thing your auditor or your lawyer will ask for.
What moves the number
- How many accounts are in Firebase Authentication, and which sign-in providers they use — some migrate cleanly, some force every user through a reset.
- Whether PHI is concentrated in Firestore or spread across Realtime Database, Storage buckets and third-party SDKs.
- Whether the app has live users, which turns a cutover into a zero-downtime migration.
- How much historical telemetry exists, since deciding what to do with data already in Analytics and Crashlytics takes longer than switching them off.
- Whether other vendors touch the same data — a payments provider, an email service, an AI API — because each one needs its own agreement and its own review.
When not to hire us
- You do not have real PHI yet. A prototype on synthetic data needs none of this, and doing it before the product shape settles usually means doing it twice.
- All you actually need is the BAA. That is signed with Google Cloud directly, and paying an agency to arrange it is paying an agency to fill in a form.
- Your app is small and already runs only on Firestore, Cloud Storage, Cloud Run functions and Identity Platform. Then this is a checklist, not a project — our free Firebase guides cover the same ground, and the self-check above is the whole audit.
- You are shopping for a compliance certificate. There is no government HIPAA certification, so nobody can sell you one — us included.
Worth knowing either way
There is no government HIPAA certification
No authority certifies software as HIPAA-compliant. What exists is a signed Business Associate Agreement with every vendor that touches protected health information, plus the administrative, physical and technical safeguards you implement and document yourself.
SOC 2 is not a substitute for a BAA
Supabase states it plainly in its own documentation: “SOC 2 does not cover, nor is it a substitute for, compliance with the Health Insurance Portability and Accountability Act (HIPAA).” The same holds for every vendor here.
An absence of documentation is not a vendor promise
Several answers here rest on what vendor documents do not say. We name which documents we read and when. A vendor that has never published a HIPAA position may still decline to sign, and one that publishes nothing today may publish something next quarter.
The same question, for the other fifteen tools
Firebase
NoOnly the Google Cloud equivalents are covered — no Firebase-branded service is
Supabase
Yes, with conditionsBAA plus a paid HIPAA add-on, on the Team plan or above
v0 by Vercel
PartiallyVercel hosting is covered; v0 itself is contractually off-limits for PHI
Lovable
NoIts terms prohibit uploading protected health information
Bubble
NoIts own documentation says apps built on Bubble won't achieve compliance
Replit
NoIts Terms, Commercial Agreement and DPA carry no HIPAA or BAA terms
Bolt.new
NoNo BAA in the StackBlitz and Bolt documents we read; HIPAA is named only for self-hosted
FlutterFlow
NoIts terms bar processing HIPAA-protected data outright
Claude Code
Yes, with conditionsCovered only with zero data retention, on accounts Anthropic qualifies
Codex
Yes, with conditionsCodex Local on a Regulated or Healthcare tier; Codex Cloud is excluded
Cursor
Yes, with conditionsEnterprise only, with Privacy Mode locked organisation-wide
GitHub Copilot
NoNo BAA offered; the Data Protection Agreement tells customers not to send PHI
Devin
NoPHI is Prohibited Data under the acceptable-use policy
Hermes Agent
Not the right questionSelf-hosted — the agreement you need is with your model provider
OpenClaw
Not the right questionSelf-hosted — but the vendor-run router still receives prompts
Base44
NoNo BAA; its terms ask customers to keep PHI off the platform
Sources, quoted as printed
Every claim above traces to one of these. Quotes are reproduced as printed on the source page. Where several entries of one list are cited, each is reproduced on its own line and no ordering or adjacency between them is implied; where a table is quoted, the header row is shown above the row cited.
The covered products are named under their Google Cloud names, and the Firebase names are not among them. We checked all 180 entries of the Covered Products list: "Firestore", "Cloud Storage", "Cloud Run functions" and "Identity Platform" are each present as separate entries; "Cloud Functions" is not an entry and "Cloud Firestore" does not appear on the page at all.
Firestore Cloud Storage Cloud Run functions Identity Platform
Google Cloud — HIPAA Compliance, Covered ProductsSource dated: Last updated 2026-08-11 UTCChecked: August 2026Google itself prints that Firebase Authentication has no BAA coverage, in its own side-by-side comparison with Identity Platform.
Feature | Identity Platform | Firebase Authentication BAA coverage | Yes | No
Google Cloud — Identity Platform product comparisonSource dated: Last updated 2026-08-20 UTCChecked: August 2026Google instructs customers not to use uncovered products with PHI at all — it is not framed as a risk to weigh but as an instruction.
Disable or otherwise ensure that you do not use Google Cloud Products that are not explicitly covered by the BAA (see Covered Products) when working with PHI.
Google Cloud — HIPAA Compliance, Essential best practicesSource dated: Last updated 2026-08-11 UTCChecked: August 2026The Covered Products page is not marketing collateral — the BAA text defines the scope of the agreement by pointing at that page, which is why the exact product names on it are contractual and why the scope can move when the page moves.
"Covered Services" means the Google products and services specifically identified at https://cloud.google.com/security/compliance/hipaa/ … as being covered by the Google Cloud Platform BAA.
Google Cloud Platform HIPAA BAA (contract text)Source dated: Last modified September 22, 2025Checked: August 2026
Frequently asked questions
We signed a BAA with Google. Doesn't that cover our whole Firebase project?
It covers what the Covered Products list names, and nothing else. Google's own guidance on the same page is blunt about it: "Disable or otherwise ensure that you do not use Google Cloud Products that are not explicitly covered by the BAA (see Covered Products) when working with PHI." So a signed BAA plus PHI in Firebase Authentication or Crashlytics is not a covered arrangement — it is PHI in products the agreement does not reach.
Everything is in Firestore already. Are we fine?
Firestore is named on the covered list, so the main record store is in the right place. The question is where copies of the same data end up: the user record in Firebase Authentication, the log line in a Crashlytics report, the event parameter in Analytics, a presence node in Realtime Database. In Firebase apps the database is rarely the problem — the surfaces around it are.
What is the difference between Firebase Authentication and Identity Platform, really?
For this question, one row. Google publishes a comparison table of the two products, and on the row labelled "BAA coverage" Identity Platform reads Yes and Firebase Authentication reads No. The same table shows Identity Platform in scope for PCI-DSS and carrying a 99.95% uptime enterprise SLA, where Firebase Authentication reads No on both.
Do we have to abandon Firebase and rebuild on something else?
Usually not. The covered services are Google Cloud products, so the practical move is to stop using the Firebase-branded services for anything containing PHI and to use the products that are actually named on the list — Firestore, Cloud Storage, Cloud Run functions and Identity Platform. The user migration off Firebase Authentication is normally the largest single piece of that work.
Is Firebase HIPAA certified?
Nothing is. There is no government HIPAA certification for a product or a company — the mechanism is a signed Business Associate Agreement with each vendor that touches PHI, plus the administrative, physical and technical safeguards on your side. If a vendor or a consultancy offers you a HIPAA certificate, they are offering something that does not exist.
How often does the covered list actually change?
We do not know how often, and that is the point. The BAA text defines "Covered Services" by pointing at a web page, so the scope of your agreement follows that page rather than a document you hold. The version we read carried the stamp "Last updated 2026-08-11 UTC". Save a dated copy each time you check, and re-check at least quarterly.
How long does the move onto covered services take?
Six to ten weeks for the engagement described above, at $13K–$25K. The service map comes first and is the cheapest part; the identity migration off Firebase Authentication is the longest single stage, and a live user base is what pushes the calendar towards the upper end because the cutover has to happen without downtime.
Can we just turn Analytics and Crashlytics off and carry on?
Switching them off stops new data flowing, which is the right first move and takes an afternoon. It does not answer what is already stored, how long it is kept, or who at your company can read it — and those are the questions someone will eventually ask you in writing. If you want that traced, cleaned and written up rather than done by feel, that is the work we do; if your app is small and the answers are obvious, do it yourself.
This page reports what Google's published documents said on the dates shown and is technical information rather than legal advice; HIPAA compliance is a property of your whole system and the processes around it, not of any single tool, and vendor terms change — verify the current terms with Google Cloud and talk to a lawyer who works in this area before relying on anything here.
