Rotate a finance integration credential without losing its accounting work

A credential used by an overnight finance job may have no obvious human user. Before replacing it, identify the bank-data import, document transfer, ledger connector, or reporting refresh that depends on it. Record which legal entities and environments it can reach, who owns the job, and who receives failure alerts.

Look for scheduled work that runs infrequently. A successful daily report after rotation does not prove that a monthly journal export or quarterly archive job has also received the replacement. Ask the technical owner to trace the actual dependency rather than guessing from the account's display name.

Microsoft's service-account guidance recommends recording purpose, ownership, permissions, credential lifetime, and dependencies. It also recommends supported managed identities where possible and limiting permissions to the required work. Those are Microsoft-specific implementation choices within a broader governance question: who is accountable when an automated finance identity stops working or has too much access?

Finance should maintain the ownership and workflow record, while the authorized technical team manages credentials through the approved secret-management process. Keep actual keys, passwords, and recovery material out of the close checklist. A reference to the controlled location is enough for the operating handoff.

Choose a change window around the affected accounting deadlines. Identify work already in progress and the point at which the old credential will stop being used. Some providers permit an overlap while others require a different replacement sequence; use the documented behavior for the actual integration.

Set a bounded recovery decision before making the change. An expired credential can require replacement, while a suspected compromise needs the security team's incident response. Re-enabling a credential believed to be compromised is not an ordinary availability workaround. The responsible team should decide how urgent continuity and access containment will be handled together.

After the technical connection succeeds, follow a permitted record through the affected job. For a read-only import, confirm the intended source population and destination update. For a workflow that can write, use an approved verification that cannot create an unintended payment or duplicate posting. A login success alone proves neither the required permission nor the correct company assignment.

Review the interruption window for queued and partly completed work. Compare source identifiers with accepted destination records before allowing retries. A new credential should resume the same controlled accounting flow, including any existing approval requirements, rather than starting an unrestricted second path.

Confirm that alerts still reach an active owner and that the next less-frequent job is covered. Where immediate execution would be inappropriate, retain a specific scheduled verification with an owner and due time.

Remove the old credential through the provider's supported process once the approved cutover conditions are met, and verify that it no longer provides the access being retired. Update expiry monitoring and the dependency register. Preserve the change record without recording either secret value.

At the next ownership review, compare the automated identity's permissions with the jobs it still runs. A connector that stopped making writes may need fewer privileges. A departed implementer should leave behind a company-owned operational record that the next authorized administrator can use without reconstructing the finance schedule.