How we got Google CASA Tier 2 for BillyBox in three weeks

The short version

On 22 June 2026, Google approved BillyBox for the restricted gmail.readonly OAuth scope. That approval was gated on a CASA Tier 2 Letter of Validation, issued by the App Defense Alliance through an authorized assessor. The formal assessment pipeline — from the first security scan to Google's green light — took about three weeks.

This is the honest account of what that involved, because when we started, most of what we could find online was either vague reassurance or people quoting five-figure penetration-test bills that don't apply at this tier.

Why a certification at all

BillyBox's whole job is to pull invoices and receipts out of your email so you never chase them again. To read a Gmail inbox, an app needs the restricted Gmail scope. Google treats restricted scopes as high-risk and requires OAuth verification before an app can use them without the alarming “this app isn't verified” consent screen. For a data-heavy scope like inbox access, verification requires a CASA — Cloud Application Security Assessment — at Tier 2 or above.

In other words: the security review wasn't optional polish. It was the thing standing between a scary consent warning and a two-click “connect Gmail” button.

What Tier 2 actually is

CASA is run by the App Defense Alliance, an industry consortium. There are three tiers. Tier 1 is a self-scan that restricted Gmail scopes do not accept, so the choice that actually costs you money is between the other two:

• Tier 2 — a structured self-assessment questionnaire aligned to the OWASP ASVS Level 1 standard, plus an automated dynamic scan, reviewed by an authorized lab that issues a Letter of Validation. This is what restricted Gmail scopes require.
• Tier 3 — a full independent penetration test from a named lab. This is the one that costs five figures. Most apps at our stage do not need it.

The trap is assuming you need Tier 3. We didn't. Tier 2 is substantially a paperwork-and-evidence exercise on top of building the product securely in the first place — which is the part that should never have been a project.

The three weeks

The formal pipeline ran roughly like this: a fresh dynamic security scan of the production surfaces to establish a clean baseline; then the 54-question self-assessment questionnaire, answered honestly with evidence attached; then the assessor's review, which came back in a few sharp rounds asking for specific proof — encryption at rest, reproducible deploys, token lifetimes; then the Letter of Validation; then Google's own review of that letter plus a product demo and our published privacy and terms pages.

The honest caveat: those three weeks sat on top of months of security-first habits. We weren't bolting security onto a finished product — the headers, the encryption, the least-privilege scope design were already there. What the three weeks bought was the evidence and validation, not the security itself. If you wait until you need the certificate to think about any of this, it is not a three-week project.

What was already in place

The questionnaire mostly asks whether you do the things a careful engineer already does. In our case, at a high level: a locked-down content-security policy and the usual hardening headers on both the app and the API; credentials encrypted at rest with authenticated encryption; passwords hashed with a strong work factor and screened against known-breached password corpora; rate limiting on every sensitive endpoint; strict per-user data isolation on every query; upload validation by actual file contents, not just extension; guards against server-side request forgery on the mail-connection paths; and — the point Google cares most about — a least-privilege OAuth scope that only ever lists and reads messages and attachments. No sending, no modifying, no deleting.

I'm deliberately keeping that list high-level. A security page is not the place to publish an attacker's reconnaissance map.

The one thing they caught

One questionnaire answer claimed a token expiry was enforced more strictly than it actually was — the control existed, but not quite the way we'd described it. The assessor caught the gap. The useful lesson: we shipped the correcting fix and attached the new evidence in the same reply, rather than arguing that the original answer was close enough. The Letter of Validation came two days later. Reviewers reward the team that fixes fast over the team that debates.

The numbers

• 54 questionnaire items; 48 answered yes/applicable, 6 not applicable or handled by documented compensating controls.
• Zero critical and zero high findings on the dynamic scan across both surfaces.
• ~3 weeks from first scan to Google approval.
• ~$540 in assessor fees — not the $30k–$80k a Tier 3 pentest lab charges. Google's own verification costs nothing.

Three things worth knowing before you start

1. There is no public “Google CASA” badge you're allowed to display. Competitors showing one are risking a trademark problem or worse. You can display your authorized assessor's shield, and you can state plainly that you passed — which is what we do.

2. This covers Google only. Outlook and Microsoft accounts are a separate process — Microsoft Publisher Verification — on its own timeline.

3. Commit your documentation as you write it. We lost an early overnight draft of the whole questionnaire to uncommitted-work churn and had to redo it. The git history is the durable layer; a dirty working tree is not.

Why it was worth it

Beyond removing the consent warning, passing CASA turned a compliance requirement into a trust signal: an independent, Google-recognized validation that an app handling your inbox takes that access seriously. For a small product asking people to connect their email, that is not a small thing.

We took BillyBox through this ourselves, as the team that also builds AI-agent automation for other companies. If you're staring down an OAuth verification or a CASA assessment and want a shortcut through the parts that aren't obvious, that's the kind of thing we help with — biro@hormesislabs.com.