Secure your environment

Horizon gives you a broad set of controls to protect your certificate lifecycle environment. This guide covers the most impactful settings to review and configure: identity and access, service account hygiene, profile hardening, approval workflows, and continuous visibility through discovery and notifications.

Work through these recommendations when you first set up a tenant, and revisit them whenever your team or infrastructure changes.

Use your corporate identity provider

The strongest single step you can take is to connect Horizon to your organisation's identity provider (IdP) rather than relying on local accounts.

When Horizon is federated to your corporate IdP:

• Authentication policies (MFA, session length, password strength) are enforced consistently.
• User accounts are automatically deactivated when someone leaves your organisation.
• Access auditing flows through your existing identity governance tooling.

Go to System > Identity Providers and configure your IdP using SAML 2.0 or OIDC. Keep at least one local administrator account as a break-glass fallback in case the IdP is unavailable, but do not use it for day-to-day access.

Apply least-privilege roles

Horizon's permission model separates what users can see from what they can do, and further distinguishes between requesting an action (which creates a pending request for approval) and executing it directly.

Assign the minimum set of permissions each user or team needs:

• Read — view certificates and inventory without performing any lifecycle action.
• Request — submit enrollment, renewal, or revocation requests that require approval before taking effect.
• Direct — execute the action immediately, bypassing the approval queue.

Only grant the direct permission to operators who are explicitly responsible for approving and executing lifecycle operations. End users and automated systems should hold at most the request permission on sensitive profiles.

Use teams to scope profile access. A profile made accessible only to a specific team is invisible and inaccessible to everyone outside it — this is the most effective way to isolate production, pre-production, and departmental certificates.

Use dedicated service accounts for automation

Any automated system — the Horizon Client agent, CI/CD pipelines, or integrations — should authenticate with a dedicated API credential, not a personal account.

For each integration:

1. Create a dedicated account or API ID in Horizon.
2. Grant it only the permissions it needs (for example, feed access to a specific discovery campaign, or request access to a specific profile).
3. Store the credentials in a secrets manager or vault, not in plain text on disk or in source control.
4. Document which system uses each credential so that rotation or revocation can be targeted.

If a service account credential is compromised, you can revoke it without affecting any other system or user.

Require approval for sensitive operations

For profiles that issue certificates to production systems or external-facing services, configure an approval workflow rather than allowing direct issuance.

When a profile is set to require approval:

• Users with the request permission submit a request that enters a pending state.
• An operator with the direct permission reviews and approves or denies it.
• The audit trail records who requested, who approved, and when.

This two-person control is especially important for:

• Profiles that issue publicly trusted certificates.
• Revocation of in-use certificates, where an accidental revocation causes an outage.
• Recovery operations that expose private key material.

To implement this, assign the request (not direct) permission to standard users and restrict the direct permission to a small group of designated approvers.

For more advanced approval workflows — such as quorum approval or approval tied to a change ticket — a third-party ITSM can be integrated using Horizon triggers. A trigger can call an external system when a request is submitted, and the external system can approve or deny it through the Horizon API once its own workflow completes.

Harden your certificate profiles

Each certificate profile controls the entire issuance policy for the certificates it produces. Lock down profiles to prevent certificates from being issued outside your intended parameters.

Key settings to review on each profile:

• Fixed fields — lock the subject fields (O, OU, C) that should not vary between certificates. Users can only edit fields you explicitly leave open.
• Allowed SAN types — restrict which Subject Alternative Name types (DNS, IP, email) are permitted on this profile. Disallow types your use case does not require.
• Key type and minimum size — enforce RSA ≥ 2048 or EC ≥ 256, and disallow legacy algorithms.
• Maximum certificates per holder — set a cap to prevent unintended certificate proliferation for the same hostname.
• Validity period — enforce a maximum validity that matches your policy. Shorter validity reduces the window of exposure if a key is compromised.

Keep your inventory current with discovery

Unmanaged certificates — issued outside Horizon, forgotten on a server, or deployed by a third party — are your highest-risk certificates. You have no visibility of their expiry and no way to detect if they are weak or compromised.

Run discovery regularly to maintain a complete inventory:

• Local scan — use horizon-cli localscan on each host to find certificates on disk and in certificate stores. Schedule it monthly as a minimum.
• Network scan — use horizon-cli netscan to probe your IP ranges and ports and find certificates presented over TLS. Run it against your entire address space, not just known servers.

Attach a grading policy to every discovery campaign. This flags weak keys, insecure algorithms, and near-expiry certificates automatically as they are found.

See Local scan and Network scan for setup instructions.

Configure expiry notifications

Horizon does not send expiry alerts by default. Set them up before certificates are in production.

Go to Notifications and add a notification for the certificate expiry lifecycle event. A practical minimum is:

• 60 days before expiry — first warning; time to plan renewal.
• 30 days before expiry — escalation; renewal should be underway.
• 7 days before expiry — urgent; act immediately or prepare for an outage.

Cover both your managed profiles and your discovery campaigns. A discovered certificate nearing expiry that you haven't migrated to a managed profile will still cause an outage when it expires.

For notifications delivered by email, the From address must be no-reply@clm.swisssign.com. Any other value will prevent delivery.

Rotate API credentials regularly

API keys issued to service accounts do not expire automatically. Without a rotation schedule, a compromised credential may go undetected indefinitely.

Establish a rotation cadence in your operational runbook — quarterly is a reasonable default for most environments. When you rotate:

1. Create the new credential in Horizon.
2. Update the consuming system with the new credential.
3. Verify the system is operating correctly with the new credential.
4. Revoke the old credential.

Never reuse credentials across multiple systems. If a single credential is shared and you need to revoke it, every system using it breaks at the same time.

Alert on abnormal usage

Horizon surfaces unusual activity through two complementary mechanisms: notification triggers that fire in real time, and the event audit log that records every action taken in the tenant.

Notification triggers for sensitive events

Configure email or webhook triggers for the following events and route them to your security team or a dedicated operations inbox:

• Key recovery (on_recover) — key recovery exposes private key material. It should happen rarely and deliberately; alert on every occurrence.
• Denied requests (on_deny_enroll, on_deny_revoke, etc.) — a cluster of denied requests may indicate an account attempting operations it is not authorised to perform.
• License usage threshold (on_license_usage) — a sudden spike in certificate issuance can indicate a misconfigured automation or an account issuing certificates outside your normal patterns. Set a threshold that reflects your expected maximum, for example 80% of your holder limit.
• Trigger errors (on_trigger_error) — a failing automation trigger can silently break deployment pipelines or leave certificates undeployed. Alert on failures so they are caught before they become outages.
• Credential expiration (on_credentials_expiration) — proactively alert before API credentials expire to avoid unexpected authentication failures in automated workflows.

Monitor the audit log for authentication activity

Every action in Horizon — including sign-ins — is recorded in the event audit log under System > Events. Use saved queries to surface activity you want to review regularly.

In particular, monitor logins from local accounts. When your tenant is federated to a corporate IdP, local account activity is exceptional by definition: the only local accounts that should be signing in are break-glass administrator accounts. Any login from a local account that is not a deliberate break-glass use warrants investigation.

Create a saved query filtering on authentication events from local identity provider accounts and review it as part of your periodic configuration audit. If your SIEM or monitoring platform supports webhook ingestion, a REST notification trigger on authentication failure events can forward them automatically.

Back up your tenant configuration

Your Horizon configuration — profiles, connectors, triggers, grading policies, datasources — represents significant operational investment. Back it up periodically so you can recover from accidental deletion or misconfiguration.

Go to System > Import/Export Configuration and export the full configuration. Store the export in a version-controlled repository or a secure backup location outside Horizon.

Note that credentials are excluded from the export by design. Document which credentials exist and what they are used for separately, so you can recreate them if you need to restore from a backup.

Audit your configuration periodically

As teams and systems change, permissions and profiles can drift from their intended state. Schedule a periodic review — at minimum annually, or after any significant team change — to check:

• Are there accounts with the direct permission that should only have the request permission?
• Are there service accounts whose associated system is decommissioned?
• Are profile field restrictions still aligned with your current policy?
• Are all discovery campaigns still enabled and running?
• Are notification recipients still current?

Small configuration drift compounds over time. Regular reviews keep your security posture aligned with your intent.