Policies are how TigerTrust turns “we should use ECDSA P-256” into a rule the platform actually enforces at issuance, renewal, and audit time. Every certificate, SSH key, and CA runs through the policy engine; violations are surfaced in dashboards, alerts, and reports.

​
Two types of policies

Operational policies

Everyday cryptographic and lifecycle rules: key strength, maximum validity, SAN validation. Managed at Policies in the navigation.

Compliance policies

Framework-aligned rules mapped to controls: SOC 2, ISO 27001, PCI-DSS, HIPAA, eIDAS. Managed under the same Policies section.

​
Operational policy types

TypeEnforcesExample rules
Key strengthMinimum key size and allowed algorithmsRSA minimum 2048 bits; allowed algorithms RSA, ECDSA; ECC minimum 256 bits
Expiry thresholdMaximum certificate lifetimeMaximum 397 days
SAN validationSAN format, count, and allowed patternsRequire at least one SAN; maximum 100 SANs; forbid wildcard patterns
Create a policy from Policies > New policy. Set the rule type, configure the thresholds, choose a severity (low, medium, high, critical), and enable it.
Setting a policy to disabled keeps it in the catalog but stops evaluation. Use this when rolling out new rules gradually — you can preview violations before enforcement begins.

​
Compliance frameworks

Compliance policies are pre-built templates aligned to specific control frameworks. Activate them from Policies > Compliance:
  • SOC 2 Trust Services Criteria (CC6.1, CC6.6, CC7.2)
  • ISO/IEC 27001:2022 Annex A (A.5.31, A.8.24)
  • PCI-DSS 4.0 (Requirement 4)
  • HIPAA Security Rule (§164.312(a)(2)(iv))
  • eIDAS 2 qualified certificate requirements
Each template creates a set of policy rules that map to the corresponding control. Violations are tagged with the framework and control number so you can generate evidence reports per framework.

​
Violation reporting

Violations appear in three places:
Policies shows tabs for “Active violations” and “Resolved” with filters by policy, severity, and resource type. Click any violation to see the affected certificate or key and the specific rule it broke.

​
How enforcement runs

  1. At issuance — TigerTrust validates the requested subject, key algorithm, key size, and SANs against every enabled policy before calling the CA. If any rule fails, the issuance is blocked and the specific rule violation is returned.
  2. At renewal — TigerTrust re-evaluates policies for the incoming certificate. If the renewed certificate would violate a newly-enabled policy, TigerTrust routes the renewal through an approval workflow instead of proceeding automatically.
  3. Continuously — A nightly policy sweep re-evaluates all managed certificates and creates violation records for anything that has drifted out of compliance since it was issued (for example, when a key-strength policy is tightened from RSA 2048 to RSA 3072).

​
Suppressions and grace periods

Real-world remediation takes time. You can suppress a violation until a specific date — the record remains visible but stops firing alerts and is excluded from “active” filters. Suppressions are recorded in the audit log so you can show auditors that nothing was silently hidden. The API surface for policy management is documented at API Reference.

Certificate templates

Bake policy-compliant defaults into templates so operators cannot get it wrong.

Alerts

Route policy violations to Slack, email, or PagerDuty.

Reports

Generate compliance evidence bundles from active policies.