Planning a Cert Rotation
Overview
Section titled “Overview”Rotating a certificate in Salesforce is straightforward. Knowing what breaks when you do it is the hard part. This guide walks through the full rotation workflow using OrgGuard’s dependency mapping, ownership tracking, and discovery refresh to plan, execute, and verify a certificate rotation without surprises.
What you’ll see
Section titled “What you’ll see”This workflow spans three screens:
- Certificates tab (inventory view): expiry countdown, source class, and Dependencies count column
- Certificate detail page: tabbed view with Certificate Info, Blast Radius (N), Ownership, Alert History, and Findings
- Scan Management page: Trigger Scan button and scan status timeline
Before you begin
Section titled “Before you begin”Confirm these prerequisites:
- OrgGuard has run at least one discovery scan (check Scan Management for the last scan timestamp)
- The certificate you plan to rotate appears in the Certificate Inventory with a non-zero dependency count
- You have the OrgGuard Admin or OrgGuard User permission set assigned
Step-by-step rotation workflow
Section titled “Step-by-step rotation workflow”Who can do this: OrgGuard Admin, OrgGuard User
Step 1: Identify the certificate to rotate
Section titled “Step 1: Identify the certificate to rotate”Open the Certificates tab and locate the certificate. Use the Expiry Window filter to find certificates expiring soon, or sort by Days Remaining to surface the most urgent ones.
Note the certificate’s Name, Source (Outbound, Inbound mTLS, or Connected App JWT), and Days Remaining.
Step 2: Review the Blast Radius tab
Section titled “Step 2: Review the Blast Radius tab”Click the certificate’s Dependencies count in the inventory (or open the detail page and click the Blast Radius tab). This shows every configuration that references the certificate and displays: “If this certificate expires, N integration(s) will fail.”
Record the following for each dependency:
| Field | Why it matters |
|---|---|
| Type | Determines the rotation procedure (Named Credential vs. the Identity Provider vs. Connected App) |
| Name | The specific configuration to update after rotation |
| Record ID | Use this to navigate directly to the configuration in Salesforce Setup |
Step 3: Check ownership
Section titled “Step 3: Check ownership”Click the Ownership tab on the certificate detail page. Note the Current Owner. If the certificate is unowned, assign an owner now using the Change Owner button so there is a clear point of contact during the rotation.
For each dependency, identify who manages that integration. This may be a different person or team than the certificate owner.
Step 4: Coordinate with stakeholders
Section titled “Step 4: Coordinate with stakeholders”Before rotating, notify:
- The certificate owner
- The owner(s) of each dependent configuration
- Any downstream teams that consume the integrations (e.g., if a Named Credential backs a customer-facing API, notify the team that owns that API)
Share the dependency list from Step 2 as the impact assessment.
Step 5: Rotate the certificate
Section titled “Step 5: Rotate the certificate”Perform the rotation in Salesforce Setup:
- Outbound certificates: Setup > Certificate and Key Management > Create or upload a new certificate, then update each dependent configuration to reference the new cert
- Inbound mTLS certificates: Work with the external partner to exchange updated certificates, then update the Mutual TLS configuration
- Connected App JWT certificates: Generate a new key pair, upload the new certificate to the Connected App, and distribute the new private key to the calling system
Step 6: Trigger a discovery refresh
Section titled “Step 6: Trigger a discovery refresh”After updating all dependent configurations:
- Navigate to Scan Management.
- Click Trigger Scan to start an immediate discovery cycle.
- Wait for the scan to complete (check the scan status on the dashboard).
OrgGuard will re-discover the certificate landscape and update dependency records to reflect the new certificate references.
Step 7: Verify findings auto-resolve
Section titled “Step 7: Verify findings auto-resolve”After the discovery refresh completes:
- Return to the Certificates tab and open the rotated certificate’s detail page.
- Check the Findings tab. If the rotation was successful:
- “Expiring Soon” or “Expired” findings should auto-resolve (status changes to “Resolved”)
- The new certificate should appear in the inventory with updated expiry dates
- Check the Blast Radius tab to confirm all dependencies now reference the new certificate.
Expected result: No open findings remain for the rotated certificate, and the new certificate shows the correct dependency map.
If findings persist after the scan, check:
- Whether all dependent configurations were updated to reference the new certificate
- Whether the new certificate’s expiry is far enough in the future to clear the policy threshold
- The Diagnostic Logging page for scan errors
Quick reference checklist
Section titled “Quick reference checklist”Use this checklist to track your rotation:
- Identified the certificate and its expiry timeline
- Reviewed all dependencies (count: ___)
- Noted the current owner and dependency owners
- Notified all stakeholders
- Rotated the certificate in Salesforce Setup
- Updated all dependent configurations
- Triggered a discovery refresh in OrgGuard
- Verified findings auto-resolved
- Confirmed new certificate appears with correct dependency map
Troubleshooting
Section titled “Troubleshooting”| Symptom | Likely cause | Fix |
|---|---|---|
| Findings did not auto-resolve after discovery refresh | The new certificate’s expiry is still within the policy alert threshold | Verify the new certificate has an expiry date beyond the configured alert window (default 90 days). Check the cert’s Certificate Info tab for the parsed expiry |
| The new certificate does not appear in the inventory after the scan | OrgGuard may have discovered it under a different name, or the scan did not reach the cert class | Check the Coverage Summary for any skipped certificate classes. Search the inventory by the new cert’s subject CN |
| Dependent configurations still reference the old certificate after rotation | Salesforce Setup was not fully updated before the scan ran | Re-check each dependency from Step 2 in Salesforce Setup. Update any remaining references, then trigger another manual scan |
| Inbound mTLS: external partner still rejects connections after rotation | The external system still presents the old certificate, or its trust store has not been updated | Confirm the partner has installed the new certificate on their side. Trigger a manual scan once they confirm so OrgGuard updates the dependency records |
| Connected App JWT: new certificate uploaded but JWT bearer flow still fails | The calling system is still using the private key corresponding to the old certificate | Confirm the calling system received and deployed the new private key generated in Step 5. JWT bearer requires both the certificate in Salesforce and the matching private key on the caller’s side |
Q: Can I use this workflow for an emergency rotation (certificate already expired)? A: Yes. Start at Step 2 (Blast Radius tab) and work through the steps. The main difference is urgency: dependent integrations are already failing. Complete Steps 2 through 5 as fast as possible, then trigger the discovery refresh to confirm resolution.
Q: Do I need to notify stakeholders if the certificate has zero dependencies? A: It is still good practice, but the blast radius is zero (or undetected). If you are confident the cert is genuinely unused, you can proceed without a stakeholder notification. Document the decision in the finding’s acknowledgment.
Q: What if the dependency list changes between Step 2 and Step 5? A: If someone modifies a dependent configuration while you are mid-rotation, re-run the dependency check (trigger a manual scan or refresh the detail page) before completing Step 5. Stale dependency data is the most common cause of missed configuration updates.