The final export succeeds, and the replacement platform passes its checks. We close the migration ticket. Then, casually over coffee, someone asks who owns the account that moved the data. It still has write access to the destination and credentials in a scheduled job. “Temporary,” apparently, described the project rather than the permission.
- Amazon Web Services (AWS) gives this familiar problem a deadline: Amazon Pinpoint reaches end of support on October 30, 2026. Its engagement features require migration, but AWS End User Messaging continues. AWS says the interfaces for text messaging, voice, mobile push, one-time passwords, and phone-number validation are unaffected.
The broader question applies to any retiring platform: which access relationships should end, and which still serve a legitimate purpose?
Give service account retirement an access owner
Employee departures usually have a recognizable trigger, at least a nudge from HR in Workday or Rippling, and a subsequent offboarding process. Service retirement can spread responsibility across procurement, engineering, data owners, and security. Canceling the contract ends the commercial relationship, but access security still needs an owner to review connected accounts, revoke obsolete permissions, and verify what must remain.
We need one accountable retirement owner, with named owners for each dependency. Their job is to secure a decision for every grant: remove it, retain it with justification, or replace it.
That includes service account security and artificial intelligence (AI) agents. An account shared by several workloads may need narrower permissions rather than deletion. Accounts or agents with no remaining purpose need a retirement decision before they become orphaned accounts or zombie AI agents. These are practical examples of the dangers of non-human identities.
- The Center for Internet Security’s Safeguard 5.5 specifies a service-account inventory containing the department owner, review date, and purpose, with reviews at least quarterly. A nonhuman account still needs accountable ownership.
- The same review should cover AI agents. The National Institute of Standards and Technology (NIST), in its August 2026 agent-identity guidance, advocates distinct identifiers, credentials, and permissions linked to the operating user or system. Our retirement inventory should include connected agents and access they’ll no longer need.
Follow access beyond the retiring application
Pinpoint gives us a good example. Its endpoint export process requires an Identity and Access Management (IAM) role that allows it to write to Amazon Simple Storage Service (S3).
The export role, destination bucket, and identities reading the exported data need separate decisions. We may retain the archive while removing the temporary writer.
AWS’s retirement guidance doesn’t promise blanket cleanup of customer-managed permissions outside Pinpoint. We should verify those dependencies ourselves.
Nor does every leftover role represent usable access. Risk depends on whether a principal can obtain credentials, policies authorize an action, and an accessible resource remains. A role trusted only by a retired service differs from one also assumable by a vendor.
For secure vendor access, inspect both sides of the relationship. AWS documents how cross-account authorization evaluates permissions in both accounts. Review who can assume a role and what that role permits afterward.
Give migration permissions an end condition
Migration often requires overlapping access. We need to read the source, write to the destination, validate the transfer, and preserve a workable rollback window.
It’s basic good practice to apply the principle of least privilege to each task. Scope permissions to the necessary resources and operations. Separate migration administration from routine operations.
Use just-in-time access where supported, with an explicit expiration. If rollback requires continued access, record the reason, owner, and deadline. For Pinpoint, plan rollback before service unavailability; retained credentials cannot extend availability. “Until everything looks fine” is difficult to enforce.
Replacement-platform provisioning deserves its own review. Copying every old administrator into the new system carries yesterday’s excess permissions into tomorrow’s environment.
Work through the service retirement checklist
Keep a short authorization register. For every dependency, record the identity, resource, permitted actions, trust conditions, purpose, owner, decision, deadline, review date, and completion evidence. Record credential references, never secret values.
- Export roles: The platform owner confirms data acceptance, removes obsolete write permissions, and records the policy change and an authorization test.
- Integration credentials: The integration owner revokes retired keys or grants through the issuing system and verifies that they no longer work.
- Cross-account trust: The receiving account’s owner removes obsolete trust and confirms that the former caller cannot assume the role.
- Scheduled jobs: The workload owner stops or redirects the schedule, checks queued retries, removes unnecessary grants, and verifies shutdown or a successful replacement run.
- Migration accounts: The migration lead closes temporary access after acceptance and the agreed rollback window, including applicable session checks.
- Replacement access: The new service owner reviews operational privileges and removes setup-only administration.
- Retained data: The data owner documents approved readers, retention requirements, and the next access review.
For example, an illustrative register entry might read: “Endpoint-export role; write to migration bucket; platform owner; remove after reconciliation; evidence: accepted export, permission removal, denied write test.”
Verify cleanup before closing the ticket
Treat deprovisioning as a change to verify. Use controlled tests to confirm an authorization denial, not merely a timeout or unavailable endpoint, while necessary operations still succeed. Retain policy changes and test results as evidence.
AWS service last-accessed information includes unsuccessful attempts; action-level reports exclude data-plane events such as object reads. Check relevant logs and their coverage, configuration, and owner confirmation. An infrequent recovery job may still matter.
Check existing sessions separately. AWS’s role-session revocation procedure can deny older sessions without preventing future assumption, and it affects all applicable sessions for the role. Shared roles need care. Service-linked roles and IAM Identity Center require different handling.
Finally, check deployment templates and access automation for anything that could recreate the grants we just removed.
Close the retirement when every dependency has evidence of removal or an approved reason to remain. A successful export is a milestone. It isn’t the last access decision.
Put service account retirement under review
Grab our free trial to identify service-account access, review unused or excessive permissions, and constrain temporary migration access across supported integrations. Trustle provides identity and entitlement inventories, time-limited access, and automated provisioning and deprovisioning where connectors exist, helping our users turn retirement decisions into access changes.
