At Veza, security is an integral aspect of the product, from the initial design to implementation, deployment, and daily operation. We embrace industry best practices including data-at-rest and inflight encryption, strict role-based access controls, and tenant isolation with zero external access.
Veza is committed to maintaining the confidentiality, integrity, and availability of customer data.
Veza is prepared to explain and demonstrate safeguards and compliance, and help meet customer security obligations.
Technology, regulations, and business change quickly. Veza will always adapt and improve safeguards to ensure entrusted data is always protected.
How is communication between Veza and customer systems protected, and is all data encrypted? Veza implements industry-standard techniques to secure data at rest and in transit. All network traffic uses SSL/TLS certificates (HTTPS). All customer data and backups use disk-level encryption.
Are user passwords encrypted in transit and during storage? Yes. Veza local user credentials are encrypted using the Argon2 cryptographic algorithm during transit and secured with AES-256 encryption at rest.
How are integration credentials secured? Integration credentials are encrypted using RSA-4096. All other credentials, such as for Jira webhooks, are encrypted using AES-256. All platform communications use TLS.
Does Veza regularly undergo penetration testing by an independent party? 3rd-party scans for network and application vulnerabilities are part of Veza's cloud, application, and network security practices. The results of these tests are available under NDA.
What metadata does Veza collect from connected systems? Veza gathers metadata such as resource names and user IDs to generate the authorization graph and map relationships between identities and resources. Veza also collects attributes, such as last activity date or bucket encryption state, for use in search and insights. Veza retains this information for the duration of a customer account. Customer data is deleted within 30 days of service termination.
Does Veza have a Business Continuity and Disaster Recovery (BCDR) plan? Yes. Veza's incident response strategy is reviewed and tested annually.
To maintain the integrity and confidentiality of customer data, strict access controls and principles of least privilege are diligently applied across all production and development environments.
Access to production and staging environments is limited to authorized Veza personnel only.
Multi-Factor authentication (MFA) is required to access all production environments and business applications
Dedicated VPN endpoint per cluster with granular access to each customer namespace
The Veza platform monitors and verifies access granted to critical systems
Veza is a 100% cloud-based solution, using native AWS security controls to provide a layer of infrastructure protection for every customer environment. Key controls include:
Dedicated Kubernetes namespace for each customer
Application Load Balancer (ALB) with Web Application Firewall (WAF) for all inbound traffic
AWS Shield for protection against DDoS attacks
Private subnet where Veza software (including control, management, and analytics) open only to incoming traffic through environment-specific WAF and ALB.
VPN endpoint and bastion host for upgrades and maintenance only accessible by authorized Veza personnel using MFA
In addition to internal scanning and testing programs, Veza implements broad penetration tests by third-party security experts on an annual basis. Your Veza account executive can provide the penetration test report.
Veza maintains SOC 2 Type II certification, demonstrating compliance in core trust service areas: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Additionally, Veza complies with the ISO 27001 standard for information security.
The SOC 2 Type 2 certification and report is available for all customers. Additional documents (such as Data Protection Policy, Data Security Exhibit, and summaries) are available on request.
Data is encrypted by default across the Veza platform, both at rest and in transit:
Communication between the Veza Control Plane and the Veza Insights Plane is always encrypted using SSL/TLS 1.2+ and AES-256 encryption.
Every Veza Insights Plane instance has a unique key pair. A public key encrypts all credentials uploaded by the customer in the Veza platform, ensuring that only the customer’s Veza Insights Plane can decrypt the credentials for that customer environment.
Disk encryption is enabled by default on all EKS compute instances, all databases, and all messaging subsystems.
Local user passwords are encrypted in transit and at rest.
Veza collects two kinds of information from customer systems: user identity information (such as first name, last name, and email) from identity providers, and resource metadata, enabling visibility and insight into privileged access.
Veza deletes all customer-related authorization metadata within 30 days of service termination, along with any reports.
Veza users with the admin or operator role can generate reports in a range of formats, including PNG, CSV, and JSON. Veza administrators and operators can elect to publish Veza notifications to email addresses or other external systems.
Veza adheres to industry standards and follows all best practices for secure software development, including:
Annual 3rd-party penetration testing
Code versioning and branching practices follow OWASP standards
Strong guidelines for error handling, availability, and security during the system design phase
For platform enhancements, Quality Assurance Engineering maintains a strong focus on automated unit testing, integration testing, and approved test plans.
All code merged to the production environment is peer-reviewed
Continuous security scanning as part of code developer flow
Separation of duties for staff who develop code and staff who push code to production
Design reviews conducted with engineering and product leadership during development and release cycles
Veza minimizes third-party vendor risks by conducting security reviews on all vendors with any level of access to systems or data.
This document includes information about Veza security practices, and answers some common questions customers ask. Please reach out to your account executive or for additional details or evidence.
Does Veza adhere to industry compliance standards and frameworks? What compliance attestations does Veza hold? Veza holds a current SOC 2 (System and Organization Controls) Type II Report and follows the ISO27001 standard for information security. See for more information and downloads.
Our security team requires additional information — who can we contact? Reach out to your Veza account executive or the support team at if you have a question that is not covered here. They will be happy to assist in providing any evidence to help meet your security obligations and requirements.
Questions and answers for enterprise customers and security teams
This document addresses advanced topics on Veza platform security. These include questions about authentication, encryption and key management, access controls, network security, and other procedures ensuring the security of our SaaS and cloud-premise deployments.
Veza's SaaS production environment runs on AWS. Our architecture emphasizes security, scalability, and efficient resource management with a multi-VPC structure. Key components include Amazon EKS for container orchestration, AWS WAF for web application security, and integrated monitoring tools.
What authentication methods does Veza support?
Interactive Users: Local User Accounts, SAML Single Sign-On, OpenID Connect (Early Access).
Non-Interactive Access: API Keys
For SAML-based authentication, do you handle user-provided XML? Do you validate XML to protect from malformed XML?
Veza accepts user-provided XML for SAML configuration. We validate the input to protect against malformed XML input.
For API authentication, do you support access tokens instead of API keys? If so, what tokens are supported?
Not at present.
Do you check if MFA is performed on the IdP side for single sign-on?
No. The desire that MFA is performed for session creation can be configured via ACR Values with OpenID Connect (OIDC). The configuration is specific your identity provider and the IdP configuration. It does not guarantee that the MFA was performed.
How long are access tokens valid? Is the duration of access tokens configurable?
The valid duration of regular session/access tokens is 20 hours (non-configurable). Session tokens must refresh every 15 minutes or will expire.
API keys do not expire.
The customer can configure session idle time on the Veza Sign-in Settings page.
Do you use cookies? How are your cookies defined?
Yes. We use cookies, including a session token, for session tracking. We assign our cookies as HTTPOnly and Secure.
Are all human users accessing Veza’s EKS backend required to use MFA?
All access to Veza's EKS backend is limited to a select few SRE individuals and requires multiple layers of MFA.
How does Veza avoid spoofing attacks, where an attacker impersonates the Veza application to gain unauthorized access?
Veza can prevent spoofing attacks. Here are the details:
Using a single SAML-based IdP (e.g., Okta) as the SSO provider.
Customers can disable local accounts.
Customers can allow a Super Admin user, managed by the customer, access for break-glass situations. This user's activity can be audited for any actions the user performs.
How does in-transit and at-rest encryption for data ingested into Veza work?
For in-transit data, we support TLS 1.3 (default) with ECDSA, RSA, and TLS 1.2; for at-rest data encryption, we use AES-256-GCM. We use GPG to encrypt the secrets for all integrations.
Encryption and storage: All storage is encrypted at rest (EBS Volumes, S3 buckets, Database storage).
How are keys managed?
We use AWS KMS to manage and secure keys.
Does Veza implement chains of trust?
We use AWS Certificate Manager (ACM) to issue our public TLS certificates. Internally, we use our own certificate authority (CA) and self-signed certificates for mTLS between services to prevent a supply chain compromise of internal communications security.
How are keys rotated? How often are keys rotated?
We rotate AWS and Veza KMS keys yearly
Certificates are rotated every 6 months
How is communication between the Insight Point and Veza platform secured?
All communication between the Veza Platform and the Insight Point is performed via TLS (Transport Layer Security). All requests are also signed to provide data authenticity and integrity.
Access Control Infrastructure: At the infrastructure level (Kubernetes cluster, tenant), what access control does Veza enforce to ensure infrastructure security?
Only specific personnel have access to production environments.
We perform quarterly access reviews to audit production environment access.
Authorized personnel can only access customer-managed clusters through a designated bastion host.
Bastion host activities are monitored and audited via SysDig.
We require SSO and MFA for all production systems.
All cluster traffic is encrypted.
All internal communications use mTLS.
All access is tracked in audit logs.
Is the network where customer data resides segmented from other networks, with only necessary ports and protocols allowed? Does Veza disable Public/Remote Access to EKS Cluster Endpoints?
Network policies isolate the tenant network. All external (incoming and outgoing) traffic is limited to the components that need it.
EKS access is only enabled from the Bastion host and limited to access from the private VPC. Public access is disabled.
Firewall and Intrusion Prevention: Does Veza Deploy Web Application Firewalls (WAFs) and intrusion prevention systems (IPS) to detect and block malicious traffic? Does Veza Regularly update signatures and rules? Is remote access to EKS cluster node groups disabled from the internet?
All external traffic must go through AWS WAF.
VPC traffic is analyzed and scanned to detect anomalies.
Signatures are updated automatically.
We restrict EKS node access to the private VPC from the bastion host.
Does Veza routinely review accounts with access to production tenants and the EKS backend to ensure no stale or unauthorized accounts exist? Do you ensure that Cluster Node Group IAM Policies are maintained? Is the worker node IAM user for cluster EKS Namespaces segmented?
Veza performs regular quarterly access reviews.
Veza maintains least-privilege IAM policies/permissions.
IAM policy integrity is maintained by regularly reconciling infrastructure-as-code configured policy against the running policy.
Tenants have strong access isolation through the IAM policy and Kubernetes Role-Based Access Controls (RBAC).
Do you support multi-tenancy? If so, can you describe how accesses are isolated among tenants?
Yes, Veza supports multi-tenancy:
Each tenant is an isolated deployment in a separate namespace
Tenant data and permissions are isolated, with controls to prevent cross-tenant data access.
Do you support RBAC for customer users in the same tenant? What roles are supported? What isolation is provided?
Veza supports four static roles:
Administrator (user management, provider management, and system settings)
Operator (access to all platform capabilities, like reports, rules, access workflows, etc.)
Access Reviewer (a specialized role for participating in access reviews)
Two additional roles are available in Early Access:
Viewer (Subset of operator role, preventing any changes or modifications)
Re-assigner (Subset of operator role, allowing re-assignment of any result in an Access Review)
Veza also supports Teams to limit access to specific integrations: users in a Team can only see data for integrations assigned to that Team.
How does Veza avoid repudiation (the inability to prove the occurrence of events or actions leading to disputes)?
Veza implements logging and monitoring to maintain an immutable record of all service activity:
Logs include the timestamp, the pod name that initiates the call, and all other operation details (which function, which line, etc.)
Logs are protected against tampering and stored immutably
We forward logs using TLS to our logging utility.
AWS CloudTrail is also used to monitor and audit access to AWS assets through the command line or console.
How does Veza avoid Denial of Services for supported integrations?
Veza implements rate limiting for all integrations.
Veza also monitors and allocates resources appropriately to handle spikes:
Default extraction intervals vary depending on the integration and can vary from 1 hour to 24 hours depending on target data source capabilities. Customers may set this to a larger time interval as desired.
Our EKS backend uses auto-scaling groups to achieve elasticity based on usage.
Resource usage is monitored and alerted on CPU, memory, and storage thresholds.
How does Veza avoid exploiting vulnerabilities to gain elevated privileges?
Veza uses strict permissions to ensure we use minimum necessary read permissions for each integration.
We audit Veza permissions and roles regularly.
Vulnerability Assessment and Patching:
Veza EKS backend must undergo regular vulnerability assessments.
Veza performs regular ECR image scans and patch images.
Veza assesses discovered vulnerabilities and patches them per CISA standards.
Veza automatically scans code dependencies continuously.
Veza keeps all system components up-to-date with a regular upgrade cadence.
Veza uses images with minimal dependencies necessary for each service.
How does Veza define data retention policies for metadata stored in the EKS backend and ensure secure deletion methods that comply with industry standards (e.g., NIST's Guidelines for Media Sanitization)?
Veza deletes all customer-related authorization metadata within 30 days of service termination, along with any reports.
All metadata is stored in encrypted S3 buckets and encrypted EBS volumes. AWS deletion policies and procedures comply with NIST guidelines for media sanitization.
Anomaly Detection: Does Veza implement behavioral analytics to detect unusual patterns in data access or system behavior, which might indicate a breach or other security incident? Does Veza maintain a detailed incident response plan and conduct regular threat isolation and mitigation drills?
Veza uses behavioral analytics to detect anomalies in CloudTrail and VPC flow logs.
Incident response plans are created and routinely reviewed.
We perform incident response drills at least annually.
Continuous Monitoring: Does Veza implement solutions like Security Information and Event Management (SIEM) systems to gather, correlate, and analyze logs from all parts of the environment? Does Veza ensure CIS controls are met for the EKS and AWS resources used to store and manage customer data? Is a CSPM used to track CIS controls?
We use GuardDuty to continuously monitor Production AWS accounts, including Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Elastic Kubernetes Service (Amazon EKS) clusters, and data stored in Amazon Simple Storage Service (Amazon S3) for malicious activity.
We use Sysdig to continuously monitor bastion host activities. Only authorized Veza personnel can use the host to access EKS and related AWS resources for the production AWS accounts.