News and Announcements

Service account lifecycle project update

Posted: 2025-10-27 12:36:40   Expiration: 2025-11-03 12:36:40

In September we hosted 3 listening sessions to discuss service account lifecycle with IT Partners. During those sessions we received a lot of great feedback and suggestions. We would like to share some common concerns and how we plan to address them.

A quick refresher: What is a service account?

Service accounts are created in M365 and are typically used by applications or for shared/changing roles (billing office, webmaster, etc.). These accounts might also be used with other campus services like Zoom and Google. For more information about service accounts, see our KnowledgeBase article: Microsoft 365 - Getting Started with Service Accounts

Why are we developing a lifecycle?

We currently host over 28,000 service accounts in our M365 environment. A lifecycle process will help us address critical concerns such as:

  • Security: Deactivating unused accounts reduces the risk associated with shared or abandoned credentials.
  • Cost:The new process will help manage costs as we anticipate future charges for licenses and storage.
  • Tenant maintenance: A regular lifecycle ensures better management and overall health of the M365 environment.

What issues were identified during the listening sessions?

Who receives account renewal email notifications?

Feedback: One of the primary issues raised was around who should receive account renewal notifications. What we heard from administrators is that emailing the service account itself is not always the best way to reach those who can speak for the account.

Our Response: By default, the notifications will go to the service account email mailbox, but domain administrators or authorized administrators will be able to change the notification address to be any, or all, of the following:

  • Authorized administrators
  • Domain administrators
  • Individuals with mailbox access, with any of the following permissions:
    • Full mailbox
    • Send as
    • Send on behalf
  • An alternate email address supplied by the administrator (e.g. a Google Group address)

Information included in the renewal notification email

Feedback: The renewal notification emails need to have sufficient context for the recipient to understand which account is expiring.

Our Response: This was great feedback and we are making the following changes to ensure that recipients understand what account is expiring:

  • We will include all of the email aliases associated with the service account in the renewal email.
  • Domain administrators will be able to add custom text to the standard renewal email, providing additional context that we may not be aware of.
  • Administrators will be able to add custom text to the renewal notification sent to a specific account or to all accounts in the domain.
  • Administrators will also be able to preview what the renewal notification will look like within the Wisc Account Admin site.

Domain admin tools for viewing account expiration and renewal status

Feedback: Domain Administrators would like to be able to easily see the renewal status of service accounts, and download a report of accounts and their expiration dates.

Our Response: The Wisc Account Admin site will have a new service account page that includes the following:

  • Expiration dates for all service accounts in the domain
  • Date when the service account is eligible to be renewed
  • Links to manage the account’s renewal activity
  • Option to export the information to a .csv file

Additionally, the individual service account page will show a log of when renewal emails were sent and who last renewed the account.

Domain admin tools for renewing accounts

Feedback: Some domain administrators would like to be able to renew service accounts rather than expecting account user(s) to respond to the renewal email.

Our Response: We are supporting this request in a couple of ways:

  • First, administrators can change the renewal notification email to go to themselves or to a custom email address (see above).
  • Second, domain and authorized administrators will be able to renew service accounts directly from the Wisc Account Admin site's account administration page. A renewal option will only appear on the page when the account is within 6 months of its expiration.

Will we grant any exemptions to this process?

Feedback: A common question was if we will offer exemptions for critical accounts to ensure they are not accidentally deleted. Examples include accounts used with ticketing systems, privileged accounts used with other services, or accounts associated with campus VIPs.

Our Response: We are working on an alternative to service accounts for some of these use cases.

We will also offer an exemption request process. The request must include a business case and will be reviewed to verify that no reasonable alternative exists.

Expiration and renewal timeline

Feedback: People are confused by the timeline for account deactivation and deletion. The Microsoft 365 team presented a 12 month timeline to deactivation but they plan to send renewal notifications 6 months after the last renewal.

Our Response: We agree and we are modifying our approach and how we describe the process.

  • Instead of setting a renewal date on the account, we will set an expiration date.
  • 6 months before the account is set to expire, we will begin sending monthly renewal notifications.
  • When an account is renewed, it will set the next expiration date to be 1 year from the original expiration date.
  • We will also develop a visual aid for the renewal lifecycle.

Example renewal:

  • Jan 5, 2026: A new service account, example-account@doit.wisc.edu, is provisioned, and the expiration date is set to Jan 5, 2027 (1 year from the creation date)
  • July 5, 2026 (6 months before expiration date): We begin sending monthly email notifications saying the account is ready for renewal
  • On Sept 15, 2026: Someone affiliated with the account clicks the renewal link and renews the service account
  • The account’s expiration date is reset to Jan 5, 2028 (1 year from the original expiration date)

Renewal emails may resemble phishing emails

Feedback: Sending a renewal email with a link that people need to click and may redirect to the NetID login page is going to look like a phish.

Our Response: Yes, it will. We hope the following will help reassure people that it is not a phishing attempt:

  • Administrators will be able to provide custom content to the renewal notification emails.
  • We will have KB articles and a robust communication campaign to raise awareness before people start receiving the notifications.

We are working on other ways to make the email look less like a phishing email. If you have other suggestions, please email us.

Records retention

Feedback: What about records retention?

Our Response: We are working with the University Archives and Office of Compliance to determine if there are records retention concerns related to deleting service accounts that are different from deleting NetID accounts or Office365 Groups. We expect to have a better answer and specific guidance prior to rollout.

Account activity reports

Feedback: Domain administrators would like a report with the last activity date for service accounts in their domains.

Our Response: Unfortunately this isn’t something we can provide. Account "activity" includes a wide range of possible actions, many of which are not directly visible within M365. If we could produce a truly meaningful report of account activity, we would take a different approach to service account lifecycle management.

Rollout timeline

We expect to begin implementing the new service account lifecycle in early 2026 in 2 phases:

  • Phase 1: All new service accounts will be provisioned with an expiration date set 1 year from their creation date.
  • Phase 2: We will begin backfilling expiration dates for all existing service accounts.

Our goal is to set expiration dates and send initial renewal notifications to all service accounts by the end of 2026. Please note that these projections may change as we finalize details and incorporate campus feedback.

Introducing Shared Mailboxes

During the listening sessions, we encountered some unique use cases:

  • Some service accounts are never accessed using the username and password associated with the account. This is especially common for:
    • Accounts that are only accessed through mailbox permissions.
    • Accounts that are set up to forward to Google groups or other campus list services.
  • Some accounts are created as a noreply address for sending mail from copiers or other campus devices, and the mailbox is never accessed or monitored.

These present some unique challenges to the service account renewal process.

In response, we are working to implement an alternative M365 account type called shared mailboxes. Here is why they will be a great alternative to service accounts.

Shared mailboxes:

  • Do not have a password that can be compromised
  • Do not require an M365 user license
  • Are accessed through mailbox permissions (full mailbox, send as or send on behalf)
  • Email can be forwarded to another non-M365 email address
  • Include 50GB of mailbox quota

Shared Mailboxes will soon be available to campus as a new account type. They have a simplified lifecycle, requiring only that the mailbox has at least one user permissioned or a valid forward set. We are currently developing documentation and aim to make Shared Mailboxes available by early 2026. Expect more details in the coming months.

Have more feedback?

If you have additional feedback regarding the Service Account Lifecycle project or the renewal process please send us an email at service-account-lifecycle-feedback@g-groups.wisc.edu.

-- Microsoft 365: Jeannine Bos