Frequently asked questions

Veribound is a Pre-Session Edge Access Control (PEAC) platform. An agent on each trusted user’s device attests it continuously, a trust-scoring engine turns those attestations into a decision, and your existing firewalls and cloud controls are kept informed of each trusted origin, the network that device is connecting from. Your edge then accepts connections only from those networks, so published services stop being reachable from the rest of the internet. Nothing enters your traffic path, nothing is replaced, and nobody changes how they sign in.

Any organization running services that people need to reach and the internet does not: VPN and remote-access portals, administrative consoles, internally hosted applications published for staff, partner and contractor access, management interfaces on equipment that has to stay online. If your answer to “who can reach this?” is currently “anyone, and then we authenticate them”, that is the gap. It suits organizations with a managed workforce of employees, contractors, and provisioned partners, and it is a poor fit for a service that must stay open to the general public, which is worth establishing early.

Through the same model as everything else: your gateway enforces and Veribound informs it, exactly as our firewall and cloud adapters work. The Integrations page names what has been verified against each vendor’s own live API, and a gateway is named there once it has been, never in advance, because a list of intentions is not a list of integrations. If a particular gateway matters to your evaluation, tell us which one and we will tell you where it stands.

Three parts. You stand up a trust control server in your own environment, on-premises or in your cloud, which carries your administrative console, your identity-provider synchronization, and the connections to your enforcement points. The agent reaches each device through whatever channel you already use to ship software; the person then activates their own token, signed into their own account on that device. Veribound operates only the service that receives attestation and returns trust decisions to your node. There is nothing to put in your traffic path. We can walk through the detail in a demo, or contact us and we will go through it with you.

Edge and firewall appliances, the major cloud platforms, identity providers and directories, and device agents for Windows, macOS, Android and iOS. In full: at the edge, Fortinet FortiGate, Fortinet FortiManager, Palo Alto Networks, Cisco Secure Firewall (FMC), Cisco Secure Firewall (FDM), Cisco Meraki MX, Juniper SRX, SonicWall, Sophos, Barracuda, Forcepoint and OPNsense; in the cloud, Amazon Web Services, Microsoft Azure and Google Cloud; and for identity and directories, Microsoft Entra ID (Azure Active Directory), Okta, Google Workspace, JumpCloud, Duo, PingOne, OneLogin, CyberArk, IBM Verify, Oracle Identity Cloud Service and Active Directory (on-premises), with many more planned. The Integrations page describes what each category does. If you do not see what you run, ask us: it may already be supported, and if it is not, it may already be planned.

An identity provider is optional. Users and groups can be created and managed manually in Veribound, and directory synchronization is there for organizations that would rather provision from the system they already run. What you do need is an enforcement point: Veribound is not the thing that blocks or permits traffic. It supplies the intelligence, and a compatible firewall, edge appliance or cloud control uses that to make and enforce the decision, under your own policies and your own change process.

It is a Linux service, and the only Veribound component you host. A virtual machine with two vCPU, 4 GB of memory and 20 GB free on /opt covers it and the PostgreSQL bundled with it. Pointed at a managed database instead, such as Amazon RDS, Azure Database for PostgreSQL or Cloud SQL, two vCPU with 2 GB of memory and 10 GB of disk is comfortable. It is tested on Debian and Ubuntu, on x86-64. It runs on hardware you own or a virtual machine in your own cloud account, and it is a control plane rather than a data plane: none of your traffic passes through it, so those figures are sized against your administrative load and do not grow with how busy the services behind it are.

It attests device posture on an ongoing basis and reports that attestation to the platform. It does not receive administrative control, cannot grant its own device trust, and is not an endpoint security product; it neither detects malware nor responds to it. Keep your EDR; the agent answers a narrower question than that.

Yes, and it is the case the alternatives handle worst. A static list only ever lets some people in and needs maintaining by hand; opening the service to a whole region, or to the world, is the other option people reach for, and neither is a good answer in a workforce that moves. That gap is exactly where Veribound is useful. Somebody moving between an office, a home connection, and a mobile hotspot keeps working without anybody updating anything, and the same applies to contractors on networks you have no visibility into.

No. MFA remains an important identity security control and should stay exactly where it is. Veribound adds a condition about the device; MFA remains a condition about the user. Losing either one leaves a gap the other was never designed to cover.

No. Veribound is not in your data path, so there is nothing for it to decrypt: your application traffic flows exactly where it flows today. What does cross the wire is the agent’s periodic heartbeat, transactional email for token activation, and agent software updates, all control-plane and none of it carrying your data. Any prospect can confirm it in seconds: install the agent and watch the outbound connections.

Veribound is not in your data path, so our availability and your traffic are separate questions. Your edge continues carrying traffic and applying the rules it holds, and the trust control server runs in your environment rather than ours. What your infrastructure does if that node stops receiving fresh trust decisions is a customer-defined behavior, agreed and validated during pilot design rather than discovered during an incident.

Yes, two ways, and they suit different moments. A demo shows the product against a setup like yours with nothing to deploy and nothing to commit. A pilot is the real thing on your own infrastructure: defined scope, rollback agreed in advance, and most start with one or two internet-facing services, which is enough to measure the change before anything wider is considered. The pilot is free for 90 days, and what it covers is set out on the Pricing page.

Yes. Organizations with 501(c) tax-exempt status receive 10% off their total quote, on production of the IRS determination letter. That is the whole test: the letter, not a description of the work. Tell us about your organization and we will apply it to your pricing.