TigerTrust treats every certificate, SSH key, and token as belonging to an identity. That identity might be a person, a Kubernetes pod, a smart meter, or a GitHub Actions workflow — the abstraction is deliberately uniform so you can answer questions like “which certificates does this service account own?” or “revoke everything issued to this device.”

​
The identity model

Every identity has a type and a small set of fields:
FieldPurpose
NameDisplay name (for example: payments-api, edge-meter-042)
TypeOne of user, application, iot_device, ci_cd, or machine
EmailOptional contact address
DepartmentBusiness grouping for filtering and reporting
OwnerThe human accountable for this identity
Statusactive, inactive, or suspended
TagsFree-form labels for search and policy targeting
Certificates and SSH keys are linked to an identity. That link turns “show me everything a workload owns” into a single inventory view.

​
Identity types

Engineers, contractors, and admins. Typically hold client-auth certificates, S/MIME certificates, or user SSH keys. Created automatically when a workspace member joins.
Backend services, batch jobs, and gRPC clients. Own TLS server certificates, mTLS client certificates, and workload SSH keys. Ideal target for policies enforcing ECDSA keys or short lifetimes.
Edge routers, sensors, cameras, and industrial gateways. Often provisioned with TPM 2.0 attestation to guarantee the private key never leaves the device. See TPM attestation.
GitHub Actions, GitLab CI, Jenkins, and Buildkite. Typically use short-lived API keys or code-signing certificates. Should be rotated more aggressively than long-lived services.
Kubernetes pods, ephemeral compute, and spot instances. May inherit identity from workload identity federation such as OIDC, IRSA, or Workload Identity.

​
Managing identities

Go to Identities in the navigation. From there you can:
  • Filter by type, department, status, or tag.
  • Drill into an identity to see every SSH key and certificate it owns.
  • Reassign ownership when someone leaves the team.
  • Suspend an identity to freeze new issuance without deleting history.

​
Why unify humans and machines?

Policy targeting

Apply “keys must be at least 3072 bits” to every iot_device identity, or “certificate lifetime must be 90 days or less” to every ci_cd identity.

Blast-radius answers

Compromised service account? Find every certificate and SSH key linked to it and revoke them all in one operation.

Ownership handoffs

When engineers change teams, reassign the owner field — no orphaned keys.

Compliance evidence

“Every production certificate has a named owner” becomes an enforceable policy, not a spreadsheet.

​
Discovery populates identities automatically

When an agent discovers a certificate on a host, TigerTrust can create or match an identity based on the service running on that host. Cloud discovery does the same for cloud resources, mapping ACM certificates or Key Vault entries to workload identities by resource name or tag patterns. Identities without an explicit owner are flagged by a compliance policy — giving you a clear list of orphaned credentials to clean up. The API surface for identity management is documented at API Reference.

SSH keys

Discovery, rotation, and CA-based signing of SSH keys per identity.

Policies

Target identity types and tags with enforceable rules.

TPM attestation

Hardware-rooted identity for IoT and edge devices.