Tough security problems?
Try a new defense

Because Hopr's technology does not rely on PKI and static secrets, the costs for expensive services such as certificates managers and secrets managers (vaults) are reducede. It also reduces costs due to service interruption when PKI certificates unexpectedly expire.

Hopr can work with any containerized infrastructure. Hopr is compatible with Kubernetes, Docker Swarm or other Infrastructure as a Service.

Workloads is a general term for operating machines and devices. It includes VMs, containerized infrastructure, mobile devices, and IoT.

Yes. A Hopr sidecar must be present with both a client and a server workload to verify trust in each and enable end-to-end encryption of their messages without a key exchange.

We recommend that sidecars only be shared between trusted workloads within an enterprise. Otherwise, sidecars should not be shared. Workloads outside the enterprise (third-party workloads) should be registered with Hopr by their enterprise and receive their own sidecars.

No. Hopr's technology does not required modifications to the code of applications or APIs. Our technology is encapsulated in a small block of code that is installed in a container with an App or API (workloads) prior to production.

A session is a series of API calls (from a client) and responses (from the API/server) needed to complete a service or function. The number of calls and responses in a session depends on the function or service being performed by the two workloads.

Some positive security implementations focus on rigorous specifications, structures, formats, and behaviors and then looks for deviations in these. Hopr's positive security establishes trust at initial registration of a workload, and then verifies workload identity and trust at every session thereafter. A chain of trust in the identity is built and strengthened with time.