# App Access and Admin Rights Can Now Carry an End Date _App access and admin rights requested in Cakewalk can now carry an end date. After it passes, Agent Cake, Cakewalk's AI provisioning agent, removes the account, including in apps without SCIM, while resetting admin rights becomes a task for the app owner._ By Gil Röder, CPO & Co-Founder Published: 2026-10-01 Source: https://www.cakewalk.security/blog/time-based-access-end-date --- Take a company whose product team lends one of its engineers to the finance team in March to rebuild the billing process. The project runs three months, so the engineer gets an account in the billing app and admin rights to change its settings. When the project ends in June, the engineer goes back to product work. In September, the company's [access review](/glossary/access-review) finds the account and the admin rights still open. For three months, someone who no longer worked on billing could change how the company bills its customers. This example shows why a request in Cakewalk can now carry an end date. ## The End Date Exists Only in the Requester's Head When the finance team brings the engineer in, everyone involved knows the billing project will end in June. Project work, audit preparation and one-off admin tasks follow the same pattern, because whoever asks for the access knows from the start how long it is needed. A request form without a duration field captures who needs which app and who approved the request. The end date stays in the requester's head, while the approved access remains until somebody remembers to remove it. [Time-based access](/glossary/time-based-access) adds that duration to requests in Cakewalk. Customers asked for it in two forms: access for a fixed window and admin rights limited to a set time. After an end date passes, [Agent Cake](https://www.cakewalk.security/agent-cake), Cakewalk's AI provisioning agent, removes the account automatically in apps set up for it. ## An End Date Only Works if Someone Removes the Access Access reviews exist to catch forgotten access like the engineer's account. The company's review caught it in September. Because a review finds access only when it runs, access that should have ended in June stays open until then. An end date closes that gap only if something acts on it. Unless the product removes the access itself, an end date turns into a ticket for the app owner, who has to sign in to the app and delete the account by hand. Removing access on its end date has a different outcome for each team: For security teams, an account that outlives its project becomes a dormant account, which keeps a working login to company data open after nobody needs it. Attackers misuse logins more than any other way into company data. [Verizon's 2026 Data Breach Investigations Report](https://www.verizon.com/business/resources/T1e0/reports/2026-dbir-data-breach-investigations-report.pdf) found credential abuse at some point in 39% of the breaches it analyzed, excluding employee errors and insider misuse, which puts it ahead of every other attack vector even though exploited vulnerabilities now start more breaches. In June 2026, an attacker got into Klue, a competitive intelligence platform, with what [Huntress](https://www.huntress.com/blog/klue-breach-investigation) called "a long-disused but still active credential" that Klue had created to prototype an integration it later abandoned. From there the attacker took the tokens connecting Klue to customers' Salesforce instances and accessed their CRM data, including Huntress's own. Removing an account on its end date keeps it from becoming a dormant account in the first place. For finance teams, the same account is a paid seat. Organizations leave an average of 36% of their SaaS licenses unused, according to the [2026 SaaS Management Index](https://zylo.com/news/2026-saas-management-index) from Zylo, a SaaS management vendor. Removing an account on time frees its seat in apps billed per user. For IT teams, an end date means fewer removal tickets for temporary access, while auditors see when each person's temporary access ends. ## Agent Cake Removes the Access Where SCIM Can't The end date comes from the request itself, where the requester sets a duration. After the end date passes, Cakewalk creates a Remove Access request automatically. Agent Cake then removes the access in apps set up for it, without anyone opening a ticket. For the engineer, that app is the billing app. It does not offer [System for Cross-domain Identity Management](/glossary/scim) (SCIM), the standard that lets identity platforms create and delete accounts through an API. Because the billing app is set up for Agent Cake, the agent signs in and deletes the engineer's account after the project ends in June. The billing app is no exception. A [Stitchflow analysis](https://www.stitchflow.com/blog/scim-vs-sso-tax-manual-provisioning) of 721 SaaS apps found that 57% do not offer SCIM at any price and 42% put it behind enterprise pricing. Removal that depends on SCIM leaves more than half of those apps to a person. ## Requesters Choose How Long They Need Access With time-based access, a request in the Cakewalk web app asks how long the access is needed. The request for the engineer's account asks for three months, which the approver can shorten before approving. Admins see the end date on the access itself and in the request log. ## Cakewalk Remembers When Admin Rights Should End The engineer also needs admin rights in the billing app, which can be requested for a set time like any other access. Admin rights matter more than the account, because they let someone change how the app works for everyone who uses it. After the end date passes, Cakewalk hands the reset to the app owner as a task, which means nobody has to track the date. ## Time-Based Access Shrinks What Access Reviews Have to Catch With time-based access in place, the engineer's account is gone after the project ends in June. The admin rights sit on the app owner's task list from the same day. When the access review runs in September, it no longer has to find either one. Access reviews stay, because a review still catches the access nobody could give an end date when it was requested. Time-based access takes care of the end dates people knew from the start, which leaves the September review less to find.