A nightly integration can stop even when the CRM, ERP and internet connection are all working. The missing piece may be the credential that lets one system prove its identity to another. If nobody owns its expiry date, the first warning can be a morning queue of unprocessed orders.
The useful business question is: can we replace the credential and prove that every dependent job still works before the old one expires? This guide focuses on planned application-credential rotation, using Microsoft Entra as a concrete example. Vendor references were checked on 11 October 2026.
Identify the credential and the process it supports
Do not confuse an application's client secret or certificate with an employee's password. Also distinguish a credential from a short-lived access token obtained with it. Different providers have different expiry and replacement rules; there is no universal renewal button for every API connection.
Build an inventory around business processes rather than a list of unexplained keys. For each integration, record:
- The source and destination systems, and the business purpose.
- The application identifier, environment and credential identifier, without copying the secret value into the register.
- Expiry date, technical owner, backup owner and approving business contact.
- Where the running application reads its credential and who can update that secure location.
- Every consumer: scheduled jobs, production workers, deployment tasks and less frequent reports.
- The last successful business transaction and where failures are reported.
A valid credential in an administration portal proves little if production still reads an older value from a different location. Ask the maintainer to trace the actual running configuration.
Decide whether a stored secret is still appropriate
Microsoft's application-credential guidance recommends certificate or federated credentials for production rather than client secrets. Workload identity federation can remove the need to manage a stored secret in supported scenarios. That is a design review, not permission to change an existing production connection without compatibility testing.
For a legacy integration that still requires a secret, document the constraint and a supported transition plan. Longer validity alone does not solve missing ownership. Certificates also need lifecycle management, and a federation setup still needs correct trust and access configuration.
ITZ's API development and integration service can assess these dependencies. Plan Your Integration Credential Review with the systems involved and their support arrangements; never include secret values or private keys.
Prepare a controlled replacement
For Entra applications, Microsoft's credential-renewal procedure describes adding the replacement, updating the application, validating the new credential in sign-in evidence and then removing the old credential. Its expiring-credentials recommendation is marked preview and has scope and licensing conditions; it should not be your only inventory or reminder mechanism.
Apply the relevant provider's rules. Some platforms support an overlap period; others invalidate the old key immediately. If overlap is unavailable, agree the interruption window, queue behaviour and recovery procedure with the business owner before changing anything.
- Confirm the replacement method and exact consumers in scope.
- Prepare the approved secret store or certificate deployment, preserving least-privilege access.
- Record the previous configuration reference and an achievable rollback route.
- Update a controlled instance or test environment first where the architecture permits.
- Deploy to all intended consumers and verify fresh authentication with the replacement.
- Remove the old credential only after the agreed evidence and observation period are complete.
If the old credential has already expired, rolling back to it will not restore authentication. If it is suspected to be compromised, this planned overlap procedure is inappropriate: incident containment may require immediate revocation and a different recovery sequence.
Test a business transaction, not just a green login
A hypothetical distributor sends approved CRM orders into its ERP. Its acceptance test should follow an authorised sample order from source through processing to the destination, with the expected identifier and fields. Use a safe test environment or an explicitly approved production test that cannot accidentally invoice a customer.
Check each worker or scheduled consumer. A process may continue using an already-issued token for a while, concealing an obsolete credential until the next authentication attempt. Include a verified fresh token request and, where relevant, a controlled restart or scheduled run.
Reconcile the waiting queue after any interruption. Do not replay everything blindly: use the safeguards in the safe integration retry guide to avoid duplicate orders or contacts. Authentication success and correct data processing are separate acceptance criteria.
Make the next expiry an owned maintenance task
Set reminders early enough for supplier lead times and testing, with escalation if the owner does not respond. Check that alerts reach a monitored team destination. Put infrequent jobs on the test list rather than waiting for month-end to discover a missed consumer.
For ongoing work, discuss software maintenance responsibilities: inventory updates, credential changes, monitoring and business-level acceptance. A rotation record should identify the new credential, affected consumers, test results and old-credential removal without exposing sensitive values.
Plan your integration credential review
Bring a list of connected systems, job schedules, expiry dates and any sanitised authentication errors. Request a scope covering ownership, supported authentication options, replacement testing and failed-job recovery. The next step is an agreed rotation plan for your actual integrations.
