One control plane.
Every certificate.
Internal and external. Server and client. Every environment, every endpoint, every renewal window – visible from one dashboard. Filter by trust domain, by profile, by expiry window, by health. The view you've never had across your entire certificate estate, and the starting point for taking control of Trust.
You can't control what you can't see.
Before you can apply the right trust model, you need to see what's actually out there. Certificates scattered across cloud providers, on-prem servers, Kubernetes clusters, edge nodes, SaaS integrations – issued by different teams, at different times, with different expiry windows. Most organisations discover certificates when they expire. [cyphrs]™ Hub starts with discovery.
[cyphrs]™ Hub's discovery engine scans your entire TLS estate from the inside – every endpoint, every certificate, every configuration.
Every certificate across every environment. Issuer, expiry, key strength, SAN coverage. The complete picture you've never had.
Protocol weaknesses, cipher misconfigurations, missing revocation checks. Scout doesn't just find certificates – it finds the risks attached to them.
Internal services running on public certificates. Systems paying the 47-day renewal tax for trust they don't need. Services that should authenticate to each other but can't – because public CAs don't issue client certificates. The insights that change your architecture.
All discovery data stays on your infrastructure. No SaaS dependency, no cloud callbacks, no data leaving your perimeter.
[cyphrs]™ Hub runs on-premises – your scan results, your certificate inventory, your Score data. Yours.
[cyphrs]™ Scout scans. [cyphrs]™ Score quantifies. Every endpoint receives a single graded assessment of its TLS posture – configuration strength, certificate health, trust model alignment. One number that tells you where you stand and where to focus first.
![[cyphrs] Score badge showing a 98 Exceptional TLS posture rating validated by Scout](/99 score.png)
Score. Remediate. Rescan.
Findings are scored. Every finding has a fix. Every fix gets verified.
Your Score is updated.
Deep TLS scan – protocol, ciphers, chain, vulnerabilities. Get your 0–100 baseline.
Actionable fixes for every finding – cipher config, protocol version, chain issues. Not just what's wrong, but how to fix it.
Verify the fix landed. Watch the score climb. Continuous – not a one-off audit.
Not every certificate needs the same trust.
To bring those certificates under [cyphrs] governance, Scout goes from observer to agent – deployed to your endpoints, collecting the detail needed to classify and adopt every certificate under the right trust model.
Each certificate gets assigned a trust model – internal or external – based on what it's protecting, where it lives, and who needs to trust it. Hub recommends. You decide. Once classified, the certificate moves to managed and the right renewal engine takes over.
Systems that don't need browser trust. Internal APIs, microservices, Kubernetes workloads, RFC 1918 ranges, .local and .internal domains. Your CA, your policies, your certificate lifetimes – and the ability to issue client certificates that public CAs simply don't offer. Scout deploys as the Trust CA client – generating CSRs, receiving signed certificates, managing deployment to the endpoint.
Systems that genuinely need public validation. Browser-facing domains, public APIs, customer-facing services. Renewal timed by the CA's own signal, not a hardcoded threshold. Scout deploys as the ACME client – handling challenges, generating CSRs, deploying certificates with zero downtime.
Every certificate now has a trust model and a policy. Scout is deployed. The lifecycle begins.
The lifecycle runs. You stay in control.
Every certificate now has a trust model, a policy, and a [cyphrs]™ Scout agent managing it at the endpoint. From here, [cyphrs]™ Hub runs the lifecycle – issuance, renewal, deployment, revocation – across both trust domains from one control plane. Three engines. One view.
Your authority. Your rules.
A private certificate authority deployed on your infrastructure. Issue server and client certificates for internal systems with policy-driven validation – no external dependency, no public CA constraints, no 47-day renewal cycles for services that never touch a browser. You define the certificate profiles. You control the lifetimes. You own the root of trust.
Certificate profiles enforce consistent governance. Lifetime, key type, SAN constraints – defined once, applied everywhere.
In-memory revocation list with built-in OCSP responder. A compromised certificate is revoked and enforced immediately, not after a propagation delay.
Internal certificates live as long as they need to. 90 days for agents, 365 for services, 5-day break-glass for emergencies. Your policy, not the browser ecosystem's.
Every issuance, renewal, and revocation event recorded. Immutable log. Compliance-ready without the compliance overhead.
Public trust. Automated properly.
Some certificates genuinely need public validation. Browser-facing domains, public APIs, customer-facing services – these stay on public CAs. But renewal doesn't have to be a cron job and a prayer. ACME ARI lets the CA signal the optimal renewal window for each certificate. Hub listens. Scout executes. Certificates deploy before the old ones expire.
The CA tells Hub when to renew – not a hardcoded threshold. Parametric renewal windows proportional to certificate lifetime. The right timing, every time.
New certificates are generated, validated, and deployed before the existing certificate expires. No gap. No manual intervention.
Renewal starts days or weeks in advance. If it fails, escalating retries begin immediately. Silent expiry doesn't happen.
Let's Encrypt, ZeroSSL, any ACME-compatible CA. Hub manages the relationship. You choose the provider.
The authentication layer public CAs can't provide.
Public CAs issue server certificates. They prove your website is who it claims to be. But they don't issue client certificates – and never have. If you want mutual authentication, where services prove their identity to each other, you need your own certificate authority. There is no public alternative.
That's why most teams never implement mTLS. Not because it's the wrong architecture – every security framework recommends it – but because the infrastructure to issue client certificates has been out of reach. [cyphrs]™ Hub's Trust CA changes that. Every service, every workload, every machine gets a certificate-based identity. The service calling your API proves it's authorised to be there. mTLS in hours, not the months it takes with traditional PKI.
Public CAs don't offer this. Hub's Trust CA issues client certificates with the same policy-driven governance as server certificates. Scoped identity for every service and workload.
Client certificates follow the same lifecycle as server certificates. Scout manages renewal at the endpoint. No manual distribution, no expired credentials, no authentication gaps.
mTLS is the infrastructure layer that makes zero-trust real. Not a policy document – an enforced authentication boundary at every service. Only possible when you own the CA.
mTLS gives services their identity. A2A gives agents theirs. Both require client certificates. Both require your own CA. See A2A Agent Identity →
Three engines, one control plane. Here's how it fits together.
Compliance by architecture, not by afterthought.
[cyphrs]™ Hub is deployed on your infrastructure, governed by your policies, and audited by your logs. Data sovereignty isn't a configuration option – it's the deployment model. Every architectural decision described above was made with regulatory requirements in mind.
Healthcare
HIPAA requires access controls, audit trails, and encryption for systems handling protected health information. Hub's certificate-based authentication, immutable audit logging, and on-premises deployment satisfy these requirements without additional compliance tooling. Mutual TLS with client certificates provides the service-level access control HIPAA demands – authentication that public CAs cannot deliver.
Financial Services
PCI DSS and SOX mandate encryption of data in transit, strong key management, and comprehensive audit trails. Hub's two-tier PKI, FIPS 140-3 validated cryptography, and policy-driven certificate governance align with these frameworks.
Government
FedRAMP and NIST 800-53 require validated cryptographic modules, controlled key management, and complete data sovereignty. Hub runs entirely within your perimeter with FIPS 140-3 approved algorithms and no external dependencies.
FIPS 140-3 validated · On-premises deployment · Complete data sovereignty · No SaaS dependency · Immutable audit trail
The control plane. Everything below lives inside it.
AI agents need [identity] certificates too.
![A2A agent-to-agent authentication flow with [cyphrs] Hub issuing identity certificates](/A2A.jpg)
A2A: Machine identity for autonomous agents.
Agent-to-Agent (A2A) communication is becoming infrastructure. Like service-to-service mTLS, A2A authentication requires client certificates – certificates that public CAs don't issue. Autonomous agents call APIs, access services, and act on behalf of systems – they need certificate-based identity that can be issued, scoped, rotated, and revoked. [cyphrs]™ Hub's Trust CA is the natural foundation for A2A agent identity. The same infrastructure that governs your services will govern your agents.
Each agent gets a certificate with precise scope – which services it can call, what actions it can take, how long the credential lives.
Agent certificates follow the same issuance, renewal, and revocation model as every other certificate in Hub. No special tooling.
Every agent credential issuance and revocation recorded. Who deployed the agent, when, and what it was authorised to do.
See what's out there.
Discovery requires zero infrastructure. No agents, no DNS changes, no commitment. Start with a scan and see where your certificates stand.