Yes. Guest accounts are identifiers under CMMC Level 2 practice IA.L2-3.5.6, so cmmc guest account inactivity requirements require them to be disabled after your organization’s defined period of inactivity. The rule does not give every guest account a permanent exception because it belongs to an external collaborator, acquired company, consultant, or partner; if the account is no longer used or needed, it must be disabled promptly.
What do cmmc guest account inactivity requirements actually require?
The official NIST SP 800-171 Rev. 2 requirement for IA.L2-3.5.6 is: “Disable identifiers after a defined period of inactivity.”
| Requirement language | Plain-English meaning | What an assessor will look for |
|---|---|---|
| Disable | Prevent the account from authenticating or using connected services. Removing a license alone is not sufficient if the account can still sign in. | An Entra ID guest object with accountEnabled set to false, or comparable evidence that sign-in has been blocked. |
| Identifiers | The requirement covers unique identities associated with people, accounts, processes, and devices. A Microsoft Entra B2B guest account is an identifier. | An account inventory that includes member users, guest users, privileged accounts, service accounts, and other scoped identifiers. |
| Defined period | Your organization must choose, document, and consistently apply an inactivity threshold. CMMC does not prescribe one universal number of days. | A policy, standard, or procedure stating the threshold and the approval authority for exceptions. |
| Inactivity | The account has not been used for the defined extended period, based on a stated and repeatable measure such as successful interactive sign-in activity. | Microsoft Entra sign-in data, review reports, and evidence showing the account was disabled after the threshold elapsed. |
For proposal and integration purposes, the important distinction is between inactive and temporarily unnecessary. A guest may need access during a transition, such as a 90-day contract novation, a system migration, or a joint proposal effort. That business need can justify keeping the account active, but it should be documented and time-bounded. Once the need ends, the identifier should be disabled as soon as possible rather than waiting for the normal inactivity cycle.
Who must be covered, and when is the inactivity rule triggered?
IA.L2-3.5.6 applies to identifiers within the system boundary that processes, stores, or transmits CUI, including the Microsoft 365 tenant services used to support that environment. In a Microsoft 365 implementation, guest accounts commonly appear in Microsoft Entra ID as users with a UserType of Guest. They may have access to Teams channels, SharePoint sites, OneDrive-shared content, Power BI workspaces, Azure subscriptions, or collaboration applications integrated with Entra ID.
Guest identities should be included even when the external user authenticates with their home organization’s credentials. The guest object in your tenant is still the local identifier that authorizes access to your tenant’s resources. Disabling it removes that authorization path.
- External partners and subcontractors: Guests invited to Teams, SharePoint, project workspaces, or proposal collaboration sites.
- Acquired-company personnel: Employees of the acquired organization who retain guest access while identity, email, and device management are consolidated.
- Consultants and temporary specialists: Outside personnel with access to controlled project data or collaboration resources.
- Guest administrators: External accounts assigned directory roles, Azure roles, or application administration rights require especially short review and inactivity periods.
- Legacy external identities: Guests created through prior projects, former teaming arrangements, or inherited tenants after an acquisition.
The trigger is the point at which the defined inactivity period expires. For example, if your policy defines inactivity as 90 consecutive days without a successful Entra ID sign-in, a guest whose last successful sign-in was 91 days ago should enter the disablement workflow. The workflow should also address guests who never redeemed an invitation or never completed a successful sign-in; otherwise, dormant invitations can remain active indefinitely.
Guest account inactivity controls should not be confused with access expiration. An expiration date is an entitlement decision based on a known end date. Inactivity is a separate safeguard based on lack of use. A mature program uses both: access expires when the engagement ends, and inactive accounts are disabled when activity stops unexpectedly.
What does compliant Microsoft 365 guest-account management look like in practice?
A compliant implementation does not require every organization to use the same threshold or automation platform. It does require a defined rule, reliable identification of inactive accounts, timely disablement, and evidence that the process operates. The following examples show approaches an assessor could reasonably validate.
- A documented 90-day guest inactivity standard. A 600-person organization defines guest inactivity as no successful interactive sign-in to Microsoft Entra ID for 90 days. The identity standard applies to all Entra ID guest users with access to the CUI collaboration tenant. It assigns the Identity and Access Management team responsibility for a monthly review and requires system owners to approve any 30-day exception. The standard also states that exceptions do not override immediate disablement when a contract, teaming agreement, or business relationship ends.
- Automated Entra ID reporting and disablement. The organization uses an Azure Automation runbook with Microsoft Graph permissions to retrieve guest users and evaluate
signInActivity.lastSuccessfulSignInDateTime. When the last successful sign-in exceeds 90 days, the runbook creates a ServiceNow task for the guest sponsor. If the sponsor does not certify a continuing need within 10 business days, the runbook updates the Entra object toaccountEnabled: false. The monthly report retains the guest UPN, sponsor, last sign-in date, review date, disposition, and ticket number. - An acquisition-transition workflow. Northstar Federal Solutions, a 420-person federal proposal and managed-services firm, acquires Meridian Program Advisors, a 75-person professional services firm. For the first 120 days, Meridian employees use Entra B2B guest accounts to access a restricted Teams site and SharePoint migration library while their identities are moved into Northstar’s tenant. Each guest is assigned a Northstar sponsor and a migration end date. After the migration cutover, guests are converted to managed member accounts where appropriate; remaining guest accounts are disabled within five business days. Guests with no successful sign-in for 45 days during the transition are disabled sooner unless the integration lead approves a documented exception.
- Access reviews paired with sign-in evidence. A program office uses Microsoft Entra ID Governance access reviews for guest access to a Teams-connected SharePoint site that supports a controlled deliverable. Reviews occur quarterly, require the resource owner to attest to each guest’s continuing need, and automatically remove site access for denied or unanswered reviews. Separately, the IAM team reviews Entra sign-in activity each month and blocks sign-in for guests inactive longer than the organization’s 90-day threshold. The access review proves authorization remains appropriate; the inactivity review proves dormant identifiers are disabled.
For evidence, retain more than a screenshot of a disabled account. A strong assessment package links the policy threshold to the operational result: the account inventory, Entra guest-user export, sign-in activity report, automation or review logs, sponsor decisions, exception approvals, ServiceNow records, and a sample showing accountEnabled set to false. During an M&A, preserve source-tenant exports as well, because inherited guest identities are easy to miss when collaboration sites and project teams are migrated in phases.
What settings and records should support the control?
Microsoft 365 can provide the data and enforcement mechanisms, but the organization must decide what its defined inactivity period means and how it will handle edge cases. A practical operating model is shown below.
| Control element | Microsoft 365 or process evidence | Example operating value |
|---|---|---|
| Guest account inventory | Microsoft Entra ID user export filtered on UserType = Guest |
Exported monthly and reconciled to the sponsor register |
| Inactivity signal | Microsoft Graph signInActivity.lastSuccessfulSignInDateTime |
No successful sign-in for 90 days |
| Never-used invitations | Entra invitation date, redemption status, and sign-in activity | Disable if not redeemed within 30 days |
| Disablement action | Microsoft Graph update to accountEnabled: false |
Disable after sponsor nonresponse or denial |
| Exception management | ServiceNow request with sponsor, reason, scope, and expiration date | Maximum 30-day extension, then re-review |
Be precise in the procedure about what counts as activity. Merely receiving an email notification or remaining a member of a Team should not be treated as account use. The procedure should identify the authoritative data source, such as successful Entra sign-in activity, and explain how administrators handle missing sign-in data, nonredeemed invitations, break-glass conditions, and users whose work is seasonal or tied to a specific deliverable.
FAQ: How do guest inactivity rules work under IA.L2-3.5.6?
Are Microsoft Entra guest accounts covered by CMMC IA.L2-3.5.6?
Yes. Entra B2B guest accounts are identifiers in your tenant and must be included when they can access systems or data within the CMMC assessment scope. Their external home identity does not remove your responsibility to disable the local guest identifier when inactive.
Does CMMC require guest accounts to be disabled after 30 days?
No. CMMC requires a defined period of inactivity, not a fixed 30-day threshold. Select a period that fits risk, contract requirements, and operating needs, document it, and apply it consistently. Higher-risk or privileged guests generally warrant shorter periods.
Is removing a guest from a Microsoft Teams site the same as disabling the account?
No. Removing Teams or SharePoint permissions limits access to that resource, but the guest may still sign in and retain access elsewhere in the tenant. IA.L2-3.5.6 calls for disabling the identifier when the inactivity threshold is met.
Can we keep guest accounts active during an M&A integration?
Yes, when there is a documented transition need, accountable sponsor, restricted scope, and defined end date. The guest inactivity rule should still apply, and accounts no longer needed for migration or business processing should be disabled immediately rather than retained for convenience.
Next step: Add Entra guest identities from both organizations to one accountable inactivity register before submitting the RFP response and before completing tenant consolidation.
