Best Practices for Certificate Discovery¶

Discovery Job Design¶

Use Focused Jobs for Each Network Segment¶

Create a separate Discovery Job for each logical network segment rather than one large job covering your entire infrastructure. Focused jobs are faster to execute, easier to interpret, and simpler to assign to the most appropriate Bridge.

A common starting structure:

Production DMZ Scan       → Bridge (DMZ)      → 10.0.1.0/24, ports 443, 8080, 8443
Internal Services Scan    → Bridge (Internal) → 10.0.0.0/16, ports 443, 636, 993
Database Tier Scan        → Bridge (Internal) → 10.0.2.0/24, ports 1433, 3306, 5432

Prefer Specific IP Ranges¶

Start with the smallest IP ranges you can meaningfully scan rather than large /8 or /16 blocks. Narrow ranges:

Complete faster, giving quicker feedback on initial setup.
Generate less unnecessary network traffic.
Produce cleaner results that are easier to review.

Expand to larger ranges once you have validated the job configuration and confirmed results are as expected.

Include Only the Ports You Need¶

Add only ports where TLS-enabled services are expected to run in the target network segment. Scanning every port on every address generates unnecessary traffic and fills the inventory with noise. Use the service type of each network segment to guide port selection — a database tier needs different ports than a web application tier.

Bridge Assignment¶

Assign Jobs to the Bridge Closest to the Target¶

A Bridge can only reach hosts on networks it has connectivity to. Assign each Discovery Job to a Bridge deployed in or adjacent to the target segment. This ensures the Bridge can establish TLS connections to hosts in the scan range.

See Bridges — Best Practices for network topology guidance.

Deploy a Bridge in Each Isolated Network Segment¶

If you have network segments that cannot reach each other (for example, separate VLANs or security zones), deploy a dedicated Bridge in each segment. A Bridge cannot discover certificates in segments it cannot route to.

Scheduling¶

Run Scans at Least Daily¶

For most environments, scheduling Discovery Jobs to run daily is sufficient to maintain an accurate inventory. More frequent scanning reduces the window between a new certificate deployment and its appearance in the inventory.

For environments with frequent certificate deployments or strict compliance requirements, consider running scans every 6–12 hours.

Stagger Schedules Across Jobs¶

If you have multiple large Discovery Jobs, stagger their cron schedules to avoid running simultaneous large scans that could strain the Bridge or generate peak network traffic. For example:

Production DMZ       → 0 1 * * *   (1am daily)
Internal Services    → 0 7 * * *   (7am daily)
Database Tier        → 0 13 * * *  (1pm daily)

Use Run Now for Spot Checks¶

The on-demand trigger is useful when you want immediate discovery feedback — for example, after deploying a new service or investigating a suspected certificate issue. Use it alongside scheduled scans rather than as a replacement.

CT Log Scanning¶

Register All Organisational Domains¶

Register every domain your organisation uses, including internal domains, vanity domains, and domains used by third-party services on your behalf. Unregistered domains create blind spots in your external certificate visibility.

Registering an apex domain (for example, example.com) automatically covers all subdomains.

Treat Unexpected CT Log Findings as Security Signals¶

Any certificate discovered via CT log scanning that was not issued through your approved workflows is a signal worth investigating. It may represent:

A certificate legitimately issued by a third party on your behalf (CDN, SaaS provider).
A certificate issued by a team outside your PKI programme.
An unexpected or potentially malicious issuance.

Establish a process for reviewing newly flagged certificates promptly.

Acting on Results¶

Review Discovered Certificates Regularly¶

Schedule regular reviews of newly discovered certificates. Focus on:

Unknown issuers — investigate any certificate from a CA that is not in your approved list.
Certificates approaching expiry — discovered certificates outside platform management will not be renewed automatically. If they should be, bring them under management before they expire.
Weak algorithm or key size — flag certificates that fall outside your cryptographic policy.
Unexpected SANs or coverage — certificates covering more domains than expected may indicate misconfiguration.

Combine Discovery with Policy Enforcement¶

Use the platform's policy engine to apply rules to discovered certificates. Policies can flag certificates that use deprecated algorithms, have excessively long validity periods, or cover domains outside an approved list.

Don't Ignore the `last_seen_at` Timestamp¶

A certificate that has not been seen in recent scans — indicated by a stale last_seen_at — may have been removed from the host it was found on. Certificates that are no longer in use should be revoked if they are still within their validity period.

Summary¶

Practice	Recommendation
Job design	One job per network segment; focused IP ranges and port lists
Bridge placement	Bridge in or adjacent to each scanned segment
Scheduling	Daily minimum; stagger large jobs
Domains	Register all organisational domains for CT log coverage
Results review	Regular review cadence; investigate unexpected issuers
Policy	Apply policy engine rules to discovered certificates
Stale hosts	Revoke certificates no longer in active use