Built around SOC 2, PCI DSS and modern encryption standards.

As a general statement of how the platform is built: data is encrypted at rest and in transit. At rest we use AES-256, the standard block cipher you would expect for stored data, and in transit we use TLS 1.3 for connections between your devices and our services. Those are the headline properties, and they are the ones worth knowing before you go further. Beyond that, the details that a security reviewer actually cares about — how encryption keys are generated, stored, rotated and separated from the data they protect, which components hold keys, how access to them is controlled and logged, and how any of this maps onto a particular deployment or region — are exactly the kind of specifics we would rather confirm for your situation than approximate on a public page, because they can differ by service and can change as the platform evolves. If your team needs that level of detail, or a written description to attach to your own risk assessment, our security team can walk through the key-management model and share the relevant documentation on request. Some of it is provided under NDA. The starting point for all of it is /contact — ask for the security team and tell us what you need to see.

Yes to both, and here is the honest shape of it rather than a checkbox. For single sign-on we support the standard enterprise protocols — OIDC and SAML 2.0 — which is what lets Vertex integrate with the major identity providers most businesses already run, so your team signs in through your own directory and you keep control of who has access from one place. For multi-factor authentication we support MFA, including hardware security keys, and we would encourage requiring the stronger factors on administrative accounts specifically, since those are the ones worth protecting hardest. What we deliberately will not do on this page is publish a definitive list of named, tested identity providers or promise that a specific provider or a specific configuration is supported out of the box, because that list evolves and the details of a given integration depend on how your directory is set up. Those are precisely the questions to put to our sales and security teams: name the identity provider you use, describe your MFA and admin-access policies, and we will confirm what is supported and what setup is involved. Start at /contact.

Both, and being precise about the line between the two matters more than any single feature. This is a shared responsibility, and confusing the two halves is how gaps happen. Our half is the platform: securing the infrastructure Vertex runs on, the application itself, the encryption of your data, and the operational security of the service we provide to you. That is ours to build, maintain and answer for. Your half is everything that lives on your side of the login. How your account is configured, who you grant access to and at what level, whether you enforce strong authentication on your team, the security of the tills, phones and computers your staff actually use, and how your people are trained to use the product day to day — those are yours, and no platform can own them for you because they happen inside your business. The one point worth stating bluntly: running Vertex does not, on its own, make your business compliant with the regulations that apply to you. Compliance for your business — data protection, payments, whatever your industry and jurisdictions require — is yours to achieve, and Vertex is one part of how you get there rather than the whole of it. If you want help understanding where our responsibilities end and yours begin for a specific requirement, our security team is happy to map it out with you at /contact.

For both, the route is our security team, and we would genuinely rather hear from you than not. If you believe you have found a vulnerability in Vertex, please report it to the security team through /contact so it reaches the right people and can be triaged properly — responsible disclosure is welcome, and getting it to us directly is far better than it sitting unreported. Please include enough detail for us to reproduce and understand what you have found; the more specific you are, the faster we can act on it. For security documentation — the audit reports, attestations, policy summaries, questionnaires and the like that your procurement or risk team may need — the same starting point applies. Tell us who you are, what you need and why, and we will share what we can through a request flow. Some of these documents are provided under NDA, because they contain detail we do not publish openly, so expect that step for the more sensitive material. In both cases the address is the same: reach the security team via /contact, and tell us plainly whether you are reporting an issue or requesting documents so we can route it correctly.