The problem: SCIM keys are about to start expiring (and nobody owns them)
Atlassian has started rolling out SCIM API key expirations (keys will be set to expire between May 1, 2026 and May 1, 2027). That’s great for security, but it creates a very real ops problem:
- SCIM provisioning breaks silently until users can’t onboard/offboard
- The “owner” of the identity provider / SCIM connector is often a departed admin
- Rotations happen under pressure, and people bypass change control “just to get it working”
This is exactly the kind of integration + governance gap where orchestration beats ad-hoc scripts.
Why this is tricky (implementation + governance)
Key rotation is not just “generate new key and paste it”:
- You need inventory (which orgs/IdPs have SCIM keys, what’s the expiry date?)
- You need approvals (rotating a provisioning credential is a change)
- You need deterministic execution (no AI guessing which connector to touch)
- You need auditability (who approved, what changed, when, and what was the outcome)
- You need rollback/containment (if provisioning fails, revert and alert)
Autom Mate is a good fit here because it supports event/scheduled triggers, API-based orchestration, supervised/approval-driven execution, and detailed logs + monitoring for audit and troubleshooting. rrn)
1) Trigger
- Scheduled trigger: run daily/weekly to detect “keys expiring soon” and “keys already expired”. Autom Mate supports scheduled triggers.
2) Validation
- Validate each canrd:
- required fields present (org, IdP, connector identifier, current expiry date)
- expiry window logic (e.g., < 45 days)
- “ownership” check (is there a current on-call group / approver mapped?)
Autom Mate supports validation + conditional branching to stop bad data from flowing into execution.
3) Approvals
- Create an approval step that includes:n- planned rotation window
- rollback plan
(Use Autom Mate’s supervised/approval-first operating model so the workflow proposes the change and waits for explicit approval before touching production.)
4) Deterministic execution
- Execution must be deterministic:
- Use a fixed mapping table: tion procedure`
- If Atlassian doesn’t have a native Autom Mate library action for this specific admin operation, execute via REST/HTTP action (Autom Mate supports “Send HTTP Request” style actions) against the vendor API/admin endpoints.
Autom Mate is designed for cross-system execution via prebuilt libraries and RESTful actions where needed.
5) Logging (audit trail)
- Write structured logs per connector:
- before/after state (redact secrets)
- approver n version
- API response summaries
Autom Mate provides execution logs and monitoring views to support auditability and troubleshooting.
6) Exception handling + rollback
- If provisioning health check fails after rotation:
- automatically revert to previous key/config (wher notify on-call
- mark the connector as “needs manual intervention”
Autom Mate supports error handling with retries, fallback actions, and notifications.
Two mini examples
Mini example A: “Expiring in 30 days” change request
- Scheduled run finds 12 SCIM keys expiring in < 30 days
- Autom Mate generates one approval per org (or poval, it rotates keys in a controlled window and logs outcomes
Mini example B: “Already expired” break-fix without panic edits
- Scheduled run detects an expired key
- Autom Mate:
- creates an urgent ticket (e.g., Jira via Autom Mate library if you use Jira)
- routes an approval to the right team
- executes the rotation playbook deterministically
- posts the final status back to the ticket
Discussion questions
- How are you currently tracking SaaS als (SCIM keys, OAuth tokens, service accounts)—spreadsheet, CMDB, or “tribal knowledge”?
- Would you prefer approvals per connector or per change window (batch rotation with one CAB-style approval)?