Auth57 security & compliance —
no PHI accepted.
Auth57 is a rule-data platform, not a patient-data platform. No protected health information is ever accepted on any API surface. That constraint — plus a short list of industry-standard controls — is what you're buying when you subscribe.
Posture at a glance
Eight things any vendor-risk team will ask, answered up front.
Why “no PHI” matters
Most healthcare vendor-risk reviews start with one question: does this vendor touch PHI?For Auth57, the answer is structurally no — and that's not marketing copy, it's an architectural constraint.
The PA Lookup API accepts four parameters: state, program, and either drug or service. None identify a patient. The API returns PA rule data — verdict, source URL, next steps — against those categorical inputs, never against a specific person.
Because we don't accept PHI, the obvious consequences apply:
- No HIPAA BAA required. HIPAA's Business Associate framework governs entities that create, receive, maintain, or transmit PHI on a covered entity's behalf. Auth57 does none of those things. Happy to sign a BAA as belt-and-suspenders if your procurement team requires it — email hello@auth57labs.com.
- Incident severity is bounded. A worst-case breach of Auth57 exposes rule lookups and API-key metadata, not patient records. No HHS breach notification. No member-facing disclosure.
- Vendor questionnaires shrink. Roughly 60% of typical VRM questions are PHI-scoped. Those questions are either N/A or answered by the architectural posture alone.
Controls in place today
Not a compliance-theater list — just what's actually configured in production.
Compliance roadmap
Honest about what's live, what's next, and what's deferred. We don't pretend to have compliance we don't have.
Responsible disclosure
If you've found a vulnerability in any Auth57 product, please email security@auth57labs.com. Include steps to reproduce and, if possible, a suggested fix. We acknowledge within 24 hours business days and will credit researchers on this page (with permission) after the issue is resolved.
We don't currently run a paid bug bounty. We do write thank-you notes and make small charitable donations on behalf of researchers who help us ship safer software.
In scope: *.auth57.io · *.auth57labs.com · the REST API · the MCP server · the subscribe flows.
Out of scope: social engineering · DoS / volumetric testing · third-party subdomains (Calendly, jsdelivr, Supabase, Stripe) · issues in old browser versions.
Vendor-risk team?
If you're evaluating Auth57 for use inside your payer, consultancy, or health-tech org — I'm happy to complete your standard vendor questionnaire, answer security follow-ups, or hop on a 30-minute call with your InfoSec team. Solo founder, direct line, no “I'll have to check with our security team.”