Email and consent
A work email, exact policy versions, optional marketing choice, and minimum request metadata are processed.
PUBLIC CONTROL DESCRIPTION01 / 06
MINIMUM PUBLIC DATA / FAIL-CLOSED ACCESS
TRUST
BOUNDARY.
Public intake verifies possession of an email address and records a service interest. It is not a customer-data portal, identity-proofing service, or confidential workspace.
IMPORTANT DISTINCTION
Email verification reduces automated abuse and confirms inbox possession. It does not verify a person's legal identity, authority, employment, or entitlement to transmit customer information.
PUBLIC ACCESS FLOW
EMAIL → CODE → SCOPEWHAT HAPPENS
Choose a service, verify the address, then open the scope workstation.
Public intake is intentionally narrow. A visitor can inspect services and request a scope discussion, but cannot upload customer artifacts.
Bot resistance
A production request requires a valid Turnstile token checked server-side for the expected action and hostname.
Single-use code
A six-digit code expires after ten minutes. Attempts and resends are bounded; response language resists account enumeration.
Short-lived access
A successful check creates a random, HttpOnly, Secure, SameSite session cookie. The service stores only a keyed token value.
COLLECTION INVENTORY
PUBLIC INTAKE ONLYDATA MINIMIZATION
Public intake collects only what access requires.
Access record
- Normalized email address
- Terms and privacy versions
- Optional marketing choice
- Selected service-interest category
Security record
- Verification and expiry state
- Keyed email, IP, code, and session values
- Consent timestamps
- Rate-limit and security events
Customer material
- Source code or credentials
- Customer datasets or production records
- Regulated or export-controlled information
- Confidential technical or commercial files
PUBLIC CONTROL SET
DEFENSE IN DEPTHIMPLEMENTED DESIGN
A small attack surface with explicit failure behavior.
Controls reduce risk; they do not create an absolute security guarantee. Production activation remains fail-closed when required configuration or approved policy versions are absent.
HTTPS at the public edge
Production traffic is intended to terminate at Cloudflare with HTTP redirected only after an active edge certificate is verified. HSTS is staged after HTTPS validation.
Restrictive response headers
Content Security Policy, frame denial, no-sniff, restrictive permissions, no-referrer, and same-origin isolation headers reduce browser attack surface.
Encrypted records, keyed lookups
Email and proposal details are encrypted separately. Keyed lookup values support access and abuse controls; codes and sessions are not stored in directly reusable form.
Layered rate limits
Global, IP-derived, and email-derived application limits supplement Cloudflare edge and Turnstile controls.
Small strict requests
JSON bodies, fields, lengths, values, methods, origins, and content types are bounded. Unknown fields and invalid states fail closed.
Bounded public records
Security events default to seven days, non-marketing access-only records to 30 days, and unconverted requests to 180 days. A verified visitor can request earlier deletion, subject to applicable legal retention.
PUBLIC SERVICE PROVIDERS
LIMITED FUNCTIONSCURRENT PUBLIC STACK
Each provider has one bounded role.
The current privacy notice and applicable signed agreement control provider use. Public-provider configuration is reviewed as part of production operations.
Edge and application
DNS, HTTPS, static delivery, abuse controls, serverless request handling, and the minimum access database.
Human verification
Produces a short-lived token that the application validates with the expected action and hostname.
Transactional email
Delivers the requested one-time code from a verified Verahelm sending domain.
PRIVATE ENGAGEMENT DATA
SEPARATE AGREEMENT REQUIREDBEFORE RECEIPT
Confidential work starts after the data route is written down.
Public verification does not create confidentiality or authorize transfer. A signed scope identifies the accepted data classes, purpose, access route, owners, subprocessors, retention, return, deletion, incident duties, and intellectual-property treatment.
- 01
Customer confirms ownership or authority for every submitted material.
- 02
Data is minimized to fields required by the evaluation contract.
- 03
Credentials and recovery material remain outside ordinary transfer packages.
- 04
Regulated, personal, export-controlled, or high-consequence information requires explicit written acceptance.
- 05
Return, retention, and deletion are confirmed at engagement closure.
SECURITY QUESTIONS
PUBLIC INTAKEPLAIN-LANGUAGE ANSWERS
What the verification channel does—and does not prove.
Why not use a mnemonic or recovery phrase?
A recovery phrase would create a new secret for customers to safeguard and a support or custody burden for Verahelm. Public access uses short-lived inbox verification; stronger returning-customer authentication can use passkeys in a separately designed workspace.
Does a verified email make the sender an authorized customer representative?
No. It demonstrates inbox possession only. Authority, identity, confidentiality, and data rights are established separately before work or private transfer.
Can code or files be submitted after verification?
Not through public intake. The verified workstation presents service information and a scoping route. Any file transfer requires an approved private engagement channel.
Does Verahelm guarantee security?
No organization can promise absolute security. Verahelm describes implemented controls, limits collection, fails closed when critical configuration is missing, and states contractual duties in the applicable agreement.
How are privacy or security questions submitted?
Privacy requests may be sent to privacy@verahelm.com. General security concerns may be sent to lab@verahelm.com without including exploit payloads, credentials, customer data, or confidential attachments.
VERAHELM HOLDINGS LLC / PUBLIC DATA BOUNDARY