Security architecture for IT and compliance buyers
InviziPoll is built so respondents stay anonymous and individual answers stay invisible to us—end-to-end encrypted poll responses are structural, not an add-on. Below is how we explain that story to your security team; for deeper dives, see our blog and the technical documentation.
Security documentation
- Encryption model overview — key hierarchy, storage, and respondent encrypted payloads (code-level detail).
- Threat model — in-scope / out-of-scope and operational caveats.
- Compliance alignment (informational) — framework mapping (not legal advice).
Post-quantum cryptography
We use the X-Wing hybrid KEM (X25519 + ML-KEM-768) for key encapsulation and ML-DSA-65 for signatures—aligning with modern standards so encrypted data resists harvest-now, decrypt-later threats.
Magic link + blind signatures
For single-vote and high-integrity flows, eligibility can be established via magic links while ballot issuance uses blind signatures—so the server never links an individual recipient to a final anonymous vote in persisted state.
Enterprise identity
Workspace owners can connect SAML 2.0 / OIDC SSO (Microsoft Entra ID, Okta, AD FS, Google Workspace, and other standards-based IdPs), provision users with SCIM 2.0, enforce verified-domain sign-in, and stream compliance-focused admin activity to SIEM webhooks—without exposing respondent content or decryption keys to those channels.
No server decryption (poll content)
We never decrypt poll answers on the server. Responses are encrypted in the respondent browser before upload; respondents stay anonymous, and we only hold encrypted data.
This page summarizes product architecture for procurement discussions. For contractual terms and data handling, see our Terms of Service and Privacy Policy.