Overview
Attend is used to run trips, incentives, and summits, which means our Customers trust us with information about their guests: contact details, travel plans, dietary and accessibility needs, and sometimes passport or visa numbers. This page explains how we protect that information. It describes how the Services work today and is provided for information only. Our contractual commitments are set out in our Terms of Service and Privacy Policy.
Secure Vault
The Secure Vault is where Attend keeps the most sensitive information an event may need, such as passport, national ID, visa, and driver's license numbers. It is end-to-end encrypted: Attend stores the data but cannot read it.
How a value is protected
- Encrypted before it leaves the device. When an attendee answers a secure form field, or a staff member enters a secure document, the value is encrypted in their browser or app using the organization's vault public key. Our servers accept only encrypted values for these fields and reject anything sent unencrypted.
- Attend holds no decryption keys. Each organization has its own vault key. Its private half is only ever stored wrapped (encrypted) to individual staff members' keys and to the organization's recovery code. Our servers never see a passphrase, a private key, or a decrypted value.
- Separated per organization. Every vault item belongs to exactly one organization's vault, and every vault lookup is restricted to that organization.
Who can read it
- Administrators grant access. An organization's owners and administrators set up its vault and approve or revoke each staff member's access. Approving access re-wraps the vault key to the new reader in the administrator's own browser. Administrative actions use a short-lived credential (three minutes), issued only after the administrator's role is re-checked.
- A personal vault passphrase. Each reader chooses a vault passphrase, separate from their Attend sign-in. It is turned into encryption keys on their device with Argon2id, a deliberately slow algorithm that resists guessing, and is never sent to us.
- Passkey unlock. A reader can also unlock the vault with a passkey (Face ID, Touch ID, Windows Hello or a security key) on their own device. The passkey's secret output (the WebAuthn PRF extension) wraps the reader's own vault key locally; we store only that wrapped copy, never the secret, so a passkey unlock gives our servers nothing a passphrase unlock doesn't. The passphrase keeps working as a fallback.
- Re-confirmation for every reveal. Revealing a value requires a fresh, single-use challenge signed with the reader's passphrase-derived key (or a passkey). A stolen session or password alone is not enough to reveal anything.
- Decrypted on the reader's device. The value is decrypted in the reader's browser or app and displayed there. Unlocked keys are held in memory only, and only for a limited time (ten minutes in the web console).
- Every reveal is logged. We record who revealed which item, when, how they re-confirmed, and from which network address, so organizations can account for access.
Recovery and limits
- Recovery code. When an organization sets up its vault, it receives a one-time recovery code that can restore access if every administrator loses their passphrase and passkeys. We cannot see or reissue it. If both the passphrases and the recovery code are lost, vault contents cannot be recovered by anyone, including us.
- Revocation. Administrators can revoke a staff member's vault access at any time. It takes effect immediately: they can no longer reveal any value, including ones they revealed before. The reveal log shows which values they viewed while they had access.
- What isn't encrypted. To list and organize vault items, we can see the document type (for example, "passport"), any label, the event and attendee it relates to, timestamps, and the access records described above. The values themselves stay encrypted.
Infrastructure
- Hosting. Attend runs on Cloudflare's global network (Cloudflare Workers, D1 databases, R2 object storage, and Durable Objects). We do not operate our own servers.
- Encryption in transit. All traffic to Attend uses HTTPS (TLS). Our API sends HTTP Strict Transport Security, so browsers refuse to connect over plain HTTP.
- Encryption at rest. Databases and file storage are encrypted at rest by our hosting provider.
- Separated data stores. Sign-in and identity data, event data, webhook data, and security audit logs live in separate databases. Uploaded files are kept in private storage. Only pages an organizer publishes are stored in public storage.
- Secrets. Signing keys and service credentials are stored as encrypted platform secrets, never in source code. The API refuses to start if a required secret is missing.
Accounts and Sign-In
- Passwordless by default. Staff and attendees sign in with a single-use, time-limited code sent to their email, and staff can also use a passkey. Asking for a code doesn't reveal whether an account exists.
- No open sign-up. Organizations are set up by Attend. Staff and attendee accounts are created only through an organizer's invitations or an event's registration. Accounts created any other way are removed automatically.
- Sessions. Session cookies are Secure, HttpOnly, and SameSite. Requests from websites we don't trust are rejected, which protects against cross-site request forgery. Signing out, revoking a session, changing a password, or deleting an account immediately invalidates the access tokens issued to that session.
- Brute-force protection. Repeated wrong invitation codes lock that email out for a period of time, and public entry points such as invitations and registration are rate limited.
- Connected tools. Integrations, including AI assistants that connect through our MCP server, use OAuth and act with the permissions of the person who connected them. API keys are scoped and rate limited.
Attendee Access
Every invited attendee gets an Attend account tied to their email address. They sign in with a one-time code that we email to them, which proves they control that address. There is no password to choose, reuse, or have stolen. Being signed in shows an attendee only the events they were invited to, never the organizer's workspace.
For attendees who can't sign in by email, for example because they can't reach their inbox at the venue, an organizer can hand over an event pass. A pass is deliberately limited:
- It works for that one event only. It gives no access to other events, to the attendee's account, or to the organizer's workspace.
- It can never be turned into an account sign-in. Email remains the only way into an account.
- We store only a hash of each pass, never the pass itself.
- The pass is exchanged for short-lived access tokens that expire within three minutes. The pass itself lapses after 90 days without use.
- A pass stops working once the attendee is removed from the event.
Access Control
- Separation between organizations. Every request is limited to the organization the user belongs to, and that check is enforced on the server for every record.
- Roles. Organizations assign owner, admin, and member roles, plus per-event roles. Each action checks the caller's role, and no one can grant a role above their own.
- Least privilege for attendee data. Contact details and notes are shown only to staff who need them, and are hidden from roles such as outside contractors. Attendees see only their own information, and anything else an organizer chooses to share.
- Attend staff access. Platform-level access is limited to a small number of Attend administrators, and changes they make are written to a protected audit log.
Monitoring and Audit
- Security-sensitive actions, including platform administrator actions and permanent deletions, are recorded in a separate audit database that the application's own interfaces cannot read or change.
- Secure Vault reveals are logged as described above.
- Each request carries an identifier so that incidents can be traced end to end.
Payments
Ticket payments are made to the organizer's own Stripe account, with the organizer as merchant of record. Attend's own subscription billing also uses Stripe. In both cases, card details are entered on Stripe's hosted checkout and never reach Attend's servers. We store only Stripe reference identifiers.
Integrations and Webhooks
- Webhooks we send are signed using the Standard Webhooks format (HMAC-SHA256), so receivers can confirm they came from Attend.
- Webhooks we receive from payment and email providers are signature-checked and time-limited before we act on them.
Service Providers
We use a small set of providers to run the Services. Each receives only what it needs for its task.
- Cloudflare: hosting, databases, storage, real-time messaging, and calls.
- Amazon Web Services: email delivery (Amazon SES) and SMS delivery.
- Apple and Google (Firebase): push notifications.
- Stripe: billing for Attend subscriptions.
- PostHog: product analytics.
Services a Customer chooses to connect, such as Slack, Cvent, or its own Stripe account for ticket sales, receive data only as that Customer configures them. Secure Vault contents are never shared with any provider, because they stay encrypted throughout.
Data Ownership and Deletion
- Our Customers own the event data they collect and decide how long to keep it. We process it on their behalf, as described in our Privacy Policy.
- Users can delete their Attend account from within the apps. Deleting an account erases its sign-in credentials, sessions, and invitation links, and anonymizes the account. Event records belong to the organizer, so requests about those should go to the organizer.
Our Security Program
- We regularly review our code and configuration for security issues, and we prioritize fixing anything we find by severity.
- Access rules are declared alongside each data model and checked automatically every time we build the Services.
- Changes go through review before release, and we test them in a separate development environment that has its own databases.
Reporting a Vulnerability
If you believe you have found a security issue in Attend, please email security@attend.vip with enough detail for us to reproduce it. Please give us a reasonable opportunity to fix the issue before disclosing it, and do not access other people's data or disrupt the Services. We appreciate responsible disclosure and will respond as quickly as we can.
Contact
For security questions, or to request more detail for a security review, contact security@attend.vip. For privacy and legal questions, contact legal@attend.vip.