Security at ZentryVoice

Architecture overview

ZentryVoice security starts with a short list of components, each chosen because it is audited and encrypts by default. The practice portal and the Control Plane are a single SvelteKit application running on Cloudflare Workers at the Cloudflare edge, so every request terminates on infrastructure with DDoS protection and a web application firewall in front of it. Rate limits, sign-in lockouts and one-time-code attempt counters live in Cloudflare KV; live call presence is fanned out through a Durable Object over server-sent events.

Voice, SMS and fax ride on Telnyx, the carrier of record. The cloud PBX for each practice is a Grandstream CloudUCM instance, activated and managed through Grandstream Device Management System (GDMS). The PBX registers its SIP trunk to sip.telnyx.com on port 5061 over TLS 1.2 or 1.3, with media carried as SRTP (AEAD_AES_256_GCM preferred). Desk phones are provisioned zero-touch by GDMS, bound to the practice by MAC address before they ship, so no credentials are ever typed into a handset.

Structured data (accounts, call detail records, message metadata, invoices, the audit log) is stored in Neon Postgres, which encrypts volumes with AES-256 and requires TLS for every connection. Binary objects (fax PDFs, invoices, exports, call-recording indexes) are stored in Cloudflare R2, which encrypts every object with AES-256-GCM. Every tenant-owned table carries a tenant_id, portal queries go through tenant-scoped helpers, and Postgres row-level security is the second fence behind them.

Identity and access

Practice users never hold a password. Signing in to the practice portal sends a 6-digit one-time code to the user’s work email; the code is hashed with a server-side pepper, expires after 10 minutes and is invalidated after 5 wrong attempts. Sign-in requests are rate-limited to 5 per 15 minutes per address and per email, and the response is identical whether or not the address exists, which prevents account enumeration. A practice session is a random 20-byte token stored only as its SHA-256 hash, carried in an httpOnly, secure cookie, valid for 30 days and renewed on use. “Sign out other devices” revokes every other session in one click.

ZentryVoice operators (the people who provision carriers, PBXs and devices) sign in through a separate realm with stricter rules. Only @zentryvoice.com identities are accepted. The password is verified with PBKDF2-SHA256 at 100,000 iterations in constant time, five failures lock the account for 15 minutes, and a correct password only yields a pending session that expires in 5 minutes unless a second factor succeeds: a passkey (WebAuthn, the default), a 30-second TOTP app code, or one of eight single-use 12-character recovery codes. Using a recovery code alerts the account owner by email and in the audit log. TOTP seeds are stored AES-GCM encrypted. Full operator sessions time out after 15 minutes idle and 12 hours absolute, record device, IP and city, and are only reachable from the operator IP allowlist. Single sign-on through Okta, Google Workspace or Microsoft Entra still requires a passkey unless the identity provider asserts MFA.

Authorization is role-based and enforced on the server, not in the interface: Owner, Platform engineer, Support and Billing roles each unlock a fixed set of actions. When Support needs to look at a practice, they open a support session that requires a written reason, is tied to a ticket, is time-boxed, and shows a persistent banner inside the practice portal. Read-only support sessions are blocked from saving anything at the HTTP layer, and every action taken during a support session is written to the practice’s audit log under the operator’s name.

• checkPractice sign-in: emailed one-time code · 10-minute expiry · 5 attempts · 5 requests per 15 minutes
• checkOperator sign-in: PBKDF2-SHA256 password · passkey, TOTP or recovery code · 15-minute idle and 12-hour absolute limits · IP allowlist
• checkServer-side RBAC with four roles; the UI hides, the server decides
• checkSupport sessions: reason required · ticket-linked · time-boxed · banner in the portal · read-only mode cannot mutate · fully audited
• checkSecurity headers on every response: a strict Content Security Policy (nonce-based scripts, no inline handlers, frame-ancestors none), HSTS with preload, nosniff, X-Frame-Options DENY, strict referrer policy, restrictive permissions policy, no-store caching for signed-in pages

Data handling

ZentryVoice is built around PHI minimization. The service only needs the data required to route, deliver and bill communications: phone numbers, timestamps, call durations, message bodies you choose to send, faxes you choose to receive, and voicemail audio. We never write message bodies or protected health information to application logs. AI call summaries and transcriptions are redacted according to the practice’s compliance policy before they are stored or written to the audit log; the practice administrator controls that policy from the Compliance page and can turn summaries off entirely.

Secrets that must be stored, such as TOTP seeds, port-out PINs and carrier account numbers, are encrypted with AES-GCM using a 256-bit key that is held as a Cloudflare secret and never written to the database. Session tokens, one-time codes, invite tokens and recovery codes are stored only as SHA-256 hashes. Fax PDFs, invoices and exports in R2 are never public: the portal issues a signed URL that expires minutes after it is generated, scoped to the requesting practice.

Retention follows the data type. Call detail records, messages and faxes stay for as long as the practice keeps its account, or longer when a practice enables the financial-services retention profile (SEC Rule 17a-4 and FINRA Rule 4511 require broker-dealer communications to be kept for at least 6 years, the first 2 in an easily accessible place). The audit log is append-only (UPDATE and DELETE are revoked from the application database role) and is retained for 6 years, matching the HIPAA documentation retention period in 45 CFR 164.316(b)(2). When an account closes, the practice can export everything first; PHI is then returned or destroyed as the BAA directs.

Compliance posture

Compliance claims are only useful when they are specific, so here is exactly what ZentryVoice holds and what it supports. ZentryVoice acts as a business associate under HIPAA for medical and dental practices and countersigns a Business Associate Agreement electronically at signup; texting and fax cannot be enabled until the BAA is signed. The platform’s controls are examined annually against the AICPA Trust Services Criteria in a SOC 2 Type II report, available under NDA from the Trust page in the portal.

On the telephony side, outbound calls from practice numbers are signed with STIR/SHAKEN A-level (full) attestation, the framework the FCC mandated under the TRACED Act, because ZentryVoice knows the customer and the number it is calling from. Every desk phone and soft extension carries a validated dispatchable location and dials 911 directly without a prefix, with a notification to the front desk, as Kari’s Law and Section 506 of RAY BAUM’s Act require of multi-line telephone systems.

Vulnerability disclosure

If you believe you have found a security issue in ZentryVoice, email security@zentryvoice.com. Include the affected URL or component, steps to reproduce, and the impact you observed. We acknowledge reports within 2 business days, give you a tracking reference, and keep you informed until the issue is resolved. We do not currently run a paid bounty program, but we credit researchers who want to be credited.

ZentryVoice follows coordinated disclosure with a 90-day window: we ask that you give us up to 90 days from acknowledgement before publishing details, and we will tell you sooner if a fix ships earlier. We extend safe harbor to good-faith research: if you follow the rules below, we will not pursue legal action or refer you to law enforcement for your research, and we will not pursue claims under the Computer Fraud and Abuse Act or similar laws for conduct that stays within them.

• checkTest only against accounts you own or have explicit permission to use; never against a real practice’s data
• checkDo not access, download or modify PHI, messages, faxes or voicemail belonging to anyone else; stop and report as soon as you can show the issue
• checkNo denial of service, spam, social engineering of staff or customers, or physical attacks on facilities
• checkDo not call 911 or emergency services from a test extension unless you are reporting a real emergency
• checkGive us 90 days before public disclosure, and do not demand payment as a condition of reporting

infoReport security issues to security@zentryvoice.com. For urgent reports involving live PHI exposure, put “URGENT” in the subject line; an on-call engineer is paged.

Sub-processors

ZentryVoice uses a small number of sub-processors to deliver the service. Each one is bound by a written agreement, and those that can touch PHI have signed a Business Associate Agreement with ZentryVoice, as the HIPAA rules require of subcontractors. We notify practice administrators by email at least 30 days before adding a sub-processor that could process PHI.

What the practice controls

Security is shared. ZentryVoice secures the platform, the carrier links and the data at rest; the practice controls who can sign in, which numbers can text, whether AI summaries run, and what the E911 address says. Administrators manage those settings in the portal, and every change is written to the audit log with the user, time and IP address. We recommend that every practice review its team list monthly, remove departed staff the day they leave, keep the E911 address current when moving suites, and enable PHI redaction for AI summaries unless a documented workflow needs the full text.