Numero security transparency

How Numero prepared for Google CASA AL1.

The real story behind our application review: what we changed, how we tested it, what reviewers asked us to prove, and what the current status does and does not mean.

Numero CASA AL1 journey from review through remediation, verification, and prepared evidence

Assessment surface

48

Requirement rows reviewed across the declared AL1 scope.

Control areas

6

Authentication through secure configuration and operations.

Current status

Evidence prepared

Application controls tested; final assessor acceptance is not claimed.

Status as of August 30, 2026: Numero completed the application remediation, live testing, and portal-evidence preparation described here. This is not a claim of certification, Google approval, or final TAC Security acceptance.

Three-part transparency series

The assessment, the architecture, and the proof.

These articles are based on Numero's readiness review, remediation report, evidence pack, scan runbooks, and requirement-level portal artifacts.

Assessment timeline

Security work, not a single scan.

The evidence pack records a sequence of review, remediation, rejection, stronger proof, and retesting.

  1. 01

    July 2026

    Independent readiness review

    The website and API were reviewed against the CASA Application Layer 1 questionnaire and OWASP ASVS. The review identified implementation, evidence, and external-artifact gaps.

  2. 02

    August 2

    Application remediation verified

    Secret validation, key separation, revocable sessions, privacy-safe logging, data retention, deletion, rate limits, TLS checks, and security headers were fixed or strengthened.

  3. 03

    August 15

    Evidence rebuilt after reviewer feedback

    Narrow or source-only submissions were replaced with complete control paths, broader scope checks, new regression tests, and live behavior evidence.

  4. 04

    August 29-30

    Authenticated scans and portal packs

    Bounded OWASP ZAP plans and companion black-box scripts were run, results were reviewed, and per-requirement evidence images were prepared for portal submission or resubmission.

What was reviewed

Six connected areas of application security.

01

Authentication

OAuth with PKCE, password hashing, account lockout, per-IP rate limits, and Turnstile before credential work.

02

Session management

Short-lived access, revocable refresh, Secure and HttpOnly cookies, logout revocation, and password-change invalidation.

03

Access control

User-scoped data access, protected modifications, narrow admin access, Origin checks, and secure OAuth callback validation.

04

Communications

TLS enforcement, authenticated encryption, strong cryptographic primitives, and indistinguishable failure behavior.

05

Data validation

Injection defenses, bounded file handling, fixed outbound destinations, safe redirects, and parameterized database queries.

06

Configuration

Dependency scanning, production fail-closed checks, strict headers, sanitized logs, secret management, and storage clearing.

What changed

The review changed the product.

Some findings were code defects. Others were missing validation, incomplete tests, or evidence that could not support its own claim. All deserved a concrete disposition.

  • Production rejects weak secrets, known development keys, non-TLS database settings, and debug logging.
  • OAuth transaction encryption was separated from source-token encryption and session signing.
  • Logout now revokes both access and refresh tokens through a server-side fingerprint store.
  • Restricted Gmail content, AI context, recipients, model output, and extracted fields were removed from logs.
  • Permanent account deletion and a 90-day temporary evaluation-data retention limit were enforced.
  • Password and support abuse controls gained rate limits; Turnstile is verified before credential work.
  • The web Content Security Policy moved to per-request nonces with strict framing and resource boundaries.
  • Security scanning now combines SAST, SCA, passive CI DAST, authenticated scans, and targeted scripts.

How proof was built

One claim, several independent ways to challenge it.

Source and tests

Complete control paths, commit-pinned references, and regression tests that actively try to break the asserted behavior.

Runtime verification

Authenticated OWASP ZAP plans plus focused black-box scripts for session, authorization, injection, and configuration behavior.

Sanitized evidence

Requirement-level statements and images with exact context, while excluding live tokens, customer data, secrets, and raw session history.

What this means for customer trust.

Numero's privacy claims are tied to enforceable controls: least-privilege Gmail access, encrypted source credentials, revocable sessions, user-scoped data access, content-free logs, and deletion and retention behavior.

The assessment process does not make incidents impossible. It makes the controls easier to inspect, the evidence harder to overstate, and regressions more likely to be caught by permanent tests and repeatable scans.

Frequently asked

Numero and CASA AL1.

Numero has completed the application-control remediation, authenticated testing, and requirement-level evidence preparation described here as of August 30, 2026. This page does not claim final assessor acceptance, certification, or endorsement until that status is formally established.

Read the framework behind the review.

CASA is maintained by the App Defense Alliance and built on the OWASP Application Security Verification Standard.

View CASA requirements

Numero is not affiliated with or endorsed by Google, the App Defense Alliance, or TAC Security. This transparency series describes Numero's own implementation and evidence status as of August 30, 2026.