MSA1.11 NE Identity Assessment

An identity assessment is the diagnostic output of Module 1. It answers three questions: What does the identity architecture look like today? What risks does it create? What does the remediation roadmap look like — prioritized, with dependencies, with cost implications? This sub assembles the assessment from the findings you produced in MSA1.1–1.10. You're not generating new queries here. You're structuring the output as a professional deliverable that justifies the architectural investment of MSA2–MSA14 to an executive audience, provides a workplan for the identity architect, and creates an audit trail for compliance.

Estimated time: 45 minutes.

Section 1 — Identity Census Summary

The census from MSA1.2 provides the foundation. the organization's tenant contains significantly more identities than the 810 "users" that appear in the default admin center view:

Identity Type        Count    Pct     Credential Management       Key Finding
-----------------    -----    -----   -------------------------   ----------------------------
Cloud-only members      87     8.6%   Entra ID                    Includes 2 break-glass accts
Synced members         723    71.9%   On-prem AD → PHS            89% of member population
Guest users            147    14.6%   Home tenant (external)      67% stale (98 of 147)
App registrations       34     3.4%   Manual (secrets/certs)      9 expired credentials
Service principals      12     1.2%   Delegated from app regs     No Workload ID CA policies
Managed identities       3     0.3%   Azure (automatic)           Correct pattern
-----------------    -----    -----   -------------------------   ----------------------------
TOTAL               1,006   100.0%                                196 non-user identities

The census tells the CISO three things immediately. First, 196 identities beyond the "810 users" — the guests, applications, and service principals that most security architectures don't account for. Second, 723 synced users (72%) that inherit every on-premises AD vulnerability. Third, 147 guest accounts representing trust relationships with external organizations — and 67% of them are stale.

Section 2 — Risk Register

Each risk entry documents: what was found, where (the evidence query), why it matters (the business impact), and what to do about it (the specific remediation).

MSA1-RISK-001 — AZUREADSSOACC account with stale Kerberos key (HIGH)

Finding: The AZUREADSSOACC computer account in on-premises AD is enabled with a Kerberos decryption key that hasn't been rotated in 410 days. Microsoft recommends 30-day rotation. NE migrated to Cloud Sync, which doesn't use Seamless SSO — the account serves no purpose.

Evidence: MSA1.5, Get-ADComputer -Filter "Name -eq 'AZUREADSSOACC'" -Properties PasswordLastSet. Key age: 410 days. Account status: Enabled.

Business impact: An attacker who extracts the AZUREADSSOACC key (via DCSync or direct AD database access) can forge Kerberos tickets that Entra ID accepts as valid SSO authentication for any synced user — without knowing the user's password. The stale key has been unchanged for over a year, giving any historical compromise persistent access.

Remediation: Disable the account immediately (Set-ADComputer -Identity "AZUREADSSOACC" -Enabled $false). Verify no Seamless SSO sign-ins in 48 hours. Delete the account. Estimated effort: 15 minutes.

MSA1-RISK-002 — Legacy Entra Connect service account with active directory permissions (HIGH)

Finding: The service account used by the decommissioned Entra Connect server still exists in both on-premises AD and Entra ID. It may still hold the Directory Synchronization Accounts role, which grants write access to all synced identity objects in Entra ID.

Evidence: MSA1.5, Get-MgDirectoryRole query for Directory Synchronization Accounts role members.

Business impact: If the service account credentials are obtained (from the powered-off server's disk, from the AD database, or from a backup), an attacker can authenticate to Entra ID with write permissions to user attributes, group memberships, and (with writeback) on-premises passwords.

Remediation: Remove from Directory Sync Accounts role. Disable in Entra ID. Verify Cloud Sync unaffected (10-minute wait + health check). Disable in on-premises AD. Estimated effort: 30 minutes.

MSA1-RISK-003 — Legacy Entra Connect server not decommissioned (HIGH)

Finding: The server that previously ran Entra Connect was powered off but not removed from the domain. The SQL LocalDB database on its disk contains sync configuration, connector spaces, and cached identity data. The server's computer account still exists in AD.

Evidence: MSA1.5, confirmed during hybrid architecture analysis.

Business impact: If the server is powered on (accidentally or by an attacker with physical access), it can authenticate to the domain. The SQL LocalDB database may contain identity data that's useful for reconnaissance. The disk should be considered sensitive data that requires secure disposal.

Remediation: Execute the 9-step decommission sequence from MSA1.5 (disable service account → verify sync health → disable on-prem account → remove from domain → wipe disk → remove DNS records → document). Estimated effort: 2-hour maintenance window.

MSA1-RISK-004 — 21 stale member accounts active for 90+ days (MEDIUM)

Finding: 21 enabled member accounts (excluding break-glass) haven't signed in for over 90 days. Two accounts have never signed in to any cloud service despite being synced from on-premises AD.

Evidence: MSA1.8, signInActivity query with 90-day threshold and break-glass exclusion.

Business impact: Active accounts with no legitimate user represent dormant access. If any of these accounts are for departed employees whose termination wasn't communicated to IT, the account provides persistent access that the former employee (or an attacker who obtains their credentials) can use.

Remediation: Contact each account's manager to confirm the user's status. Disable accounts confirmed as departed. For the two "never signed in" accounts, check on-premises AD lastLogonTimestamp to determine if they're active on-premises. Estimated effort: 2–3 hours of investigation.

MSA1-RISK-005 — 98 stale guest accounts (67% of all guests) (HIGH)

Finding: 98 of 147 guest accounts are stale: 34 PendingAcceptance (oldest: 3+ years), 12 blank-state (created via implicit sharing), 52 accepted but inactive for 180+ days. No guest access review process exists. Default guest permissions allow directory enumeration.

Evidence: MSA1.8, guest signInActivity and ExternalUserState analysis.

Business impact: Each stale guest is a trust relationship with an external organization that nobody monitors. PendingAcceptance guests represent invitation links that could potentially be accepted by anyone who compromises the guest's email address. Default guest permissions (guestUserRoleId: 10dae51f-...) allow all 147 guests to enumerate the organization's users, groups, and applications.

Remediation: Delete 31 pending invitations >90 days old (immediate, no business impact). Disable 12 blank-state guests (review SharePoint sharing dependencies). Disable 52 accepted-but-inactive guests (review with original resource owners — requires coordination). Restrict guest permissions to most restrictive level (MSA3). Estimated effort: 4 hours for deletion/disable + ongoing review process.

MSA1-RISK-006 — 4 abandoned application registrations (MEDIUM)

Finding: 4 app registrations have expired credentials and have never authenticated through their service principals. They were registered but never completed or went live.

Evidence: MSA1.8, app registration credential + service principal sign-in correlation.

Business impact: Each abandoned registration is unnecessary attack surface. If someone creates a new valid credential for the registration (which any admin with Application Administrator role can do), the application becomes active with whatever permissions were originally requested.

Remediation: Delete all 4 registrations. No active function, no dependencies. Estimated effort: 15 minutes.

MSA1-RISK-007 — 4 app registrations with expired credentials but previous sign-in activity (HIGH)

Finding: 4 app registrations have expired credentials but their service principals show historical sign-in activity. The HR Data Sync app has expired credentials but showed a sign-in as recently as June 2025 — indicating an unexplained authentication mechanism.

Evidence: MSA1.8, credential expiration + SignInActivity.LastSignInDateTime correlation.

Business impact: Applications with expired credentials that previously authenticated may indicate: active tokens with long lifetimes still in circulation, credentials stored in Key Vault that weren't captured in the app registration query, or delegated authentication on behalf of users. The HR Data Sync case is the most concerning — it has access to user attribute modification APIs and is authenticating through an unknown mechanism.

Remediation: Investigate each application with the development/operations team that created it. Determine current status (still needed vs abandoned). If needed, rotate credentials and review API permissions. If not needed, delete. The HR Data Sync investigation is urgent — determine how it's authenticating. Estimated effort: 4–8 hours of investigation.

MSA1-RISK-008 — 27 disabled accounts with residual group memberships (MEDIUM)

Finding: 27 of 31 disabled synced accounts retain active group memberships. One account (Robert Finch) has 14 group memberships. The leaver process disabled accounts but never cleaned up access.

Evidence: MSA1.8, disabled account group membership query.

Business impact: If any disabled account is re-enabled (in on-premises AD, where it propagates via sync), the user instantly regains access to all resources mediated by those groups. This is a one-command reactivation of full access — Set-ADUser -Identity "r.finch" -Enabled $true.

Remediation: Run the group cleanup script from MSA1.8 for all 27 accounts. Note that synced group memberships must be cleaned up in on-premises AD, not in Entra ID. Cloud-only group memberships can be cleaned directly. Estimated effort: 1–2 hours.

Section 3 — Architecture Decision Records

Three ADRs document deliberate architectural decisions:

ADR-MSA1-001 — Single-tenant architecture (MSA1.1). NE operates a single Entra ID tenant. Alternatives considered: multi-tenant for regulatory isolation, B2B for external collaboration platform, B2C for customer-facing applications. All rejected — the organization's regulatory environment (ISO 27001, Cyber Essentials Plus) doesn't require data sovereignty separation, and B2B/B2C introduce complexity without current business requirements.

ADR-MSA1-002 — Cloud Sync with PHS (MSA1.4). Cloud Sync is the sync engine, PHS the authentication method. Alternatives rejected: legacy Entra Connect (Microsoft's stated direction is Cloud Sync), PTA (introduces on-premises authentication dependency and reduces Identity Protection with no regulatory justification), federation/AD FS (maximum infrastructure complexity for no benefit given the organization's requirements). Password writeback retained for SSPR with MFA as compensating control.

ADR-MSA1-003 — Naming convention standard (MSA1.9). Structured naming for all Entra ID objects: groups ({Type}-{Scope}-{Purpose}), CA policies (CA-{Persona}-{Action}-{Scope}), app registrations (App-{Env}-{Purpose}-{Owner}), AUs (NE-{Scope}-{Name}). M365 group naming policy configured with blocked words. Security group naming enforced via weekly compliance audit script.

Section 4 — Additional findings (improvement opportunities)

These findings don't create immediate exploitable risk but limit the effectiveness of downstream security controls:

No Administrative Units (MSA1.6) — All admin roles operate at tenant scope. A Helpdesk Administrator at any site can reset any user's password, including the CISO's. The MSA1.6 AU design is complete but not yet implemented. Impact: every admin action has maximum blast radius until AUs are deployed.

No Lifecycle Workflows (MSA1.7) — The JML lifecycle is entirely manual. Access accumulates on every role change (SOC Analyst 2: 11 groups, 8 stale). Impact: access reviews (MSA12) will find widespread over-provisioning because the mover stage has never been managed.

HR system not connected (MSA1.7) — employeeHireDate and employeeLeaveDateTime at 0% coverage. Time-based lifecycle triggers can't fire. Impact: lifecycle automation (MSA12) is blocked until the HR data pipeline is established. This is a cross-functional project requiring HR stakeholder engagement.

No CA policies for workload identities (MSA1.3) — 34 app registrations and 12 service principals bypass all CA policies. No Workload ID Premium licensing. Impact: the entire workload identity population authenticates outside the CA framework — no MFA, no device compliance, no risk evaluation, no location restriction. MSA3 designs the workload CA policies.

Guest permissions at default level (MSA1.3) — guestUserRoleId set to default, allowing 147 guests to enumerate the directory. Impact: any guest (including compromised guest accounts) can list the organization's users, groups, and application registrations. MSA3 restricts this as part of the CA framework.

214 groups with 31 empty and 67 ownerless (MSA1.10) — Group sprawl prevents governance automation. Access reviews can't run for groups without owners. Impact: MSA12's governance architecture inherits a dirty group landscape that must be cleaned before reviews are effective.

No role-assignable groups (MSA1.10) — All Entra role assignments are direct user-to-role. Impact: PIM (MSA4) can't use group-based role activation, and role assignments can't be reviewed through group access reviews.

SMS authentication method enabled (MSA1.5) — SMS is in the Authentication Methods Policy. Impact: users can register SMS as an MFA method. SMS is vulnerable to SIM swapping, SS7 interception, and social engineering against mobile carriers. MSA2 evaluates whether SMS should remain enabled.

Section 5 — Remediation Roadmap

The roadmap is organized by urgency and dependency. Some fixes enable other fixes — the dependency chain determines the order.

Tier 1 — Immediate (this week, no dependencies, no production risk)

1. Disable AZUREADSSOACC — 15 minutes, zero risk
2. Remove legacy Connect service account from Directory Sync role — 30 minutes, verify sync health
3. Delete 28 empty groups older than 180 days — zero members, zero impact
4. Delete 31 stale pending guest invitations older than 90 days — never accepted, no active access
5. Delete 4 abandoned app registrations — never authenticated, no function

Combined estimated effort: 2 hours. No approval needed beyond change management notification. No business impact.

Tier 2 — Short-term (this month, requires investigation/coordination)

1. Investigate 21 stale member accounts — contact managers, disable confirmed stale
2. Investigate 4 expired-active app registrations — determine if applications still needed
3. Remove group memberships from 27 disabled accounts — run cleanup script
4. Assign owners to 67 ownerless groups — prerequisite for MSA12 access reviews
5. Execute 9-step decommission of legacy Entra Connect server — schedule maintenance window

Combined estimated effort: 2–3 days. Requires manager and app owner engagement.

Tier 3 — Medium-term (this quarter, requires project planning)

1. Implement AU structure from MSA1.6 — 6 site AUs + 2 function AUs + 1 restricted AU
2. Establish naming convention — rename 127 non-compliant groups in batches
3. Create license groups and migrate from direct to group-based licensing
4. Disable 52 accepted-but-inactive guest accounts — requires resource owner review
5. Restrict guest permissions — change guestUserRoleId to most restrictive

Items 11–12 are prerequisites for effective CA policy design in MSA3. Items 13–15 are prerequisites for lifecycle automation in MSA12.

Tier 4 — Long-term (next two quarters, cross-functional project)

1. Establish HR provisioning connector — connect HR system to Entra ID via API-driven provisioning
2. Implement Lifecycle Workflows — joiner, mover, leaver templates (requires item 16 for time-based triggers)
3. Consolidate groups from 214 to ~74 — target architecture from MSA1.10 (requires items 9, 12)
4. Create role-assignable groups for PIM — prerequisite for MSA4 (requires PIM licensing decision)

Item 16 is the single largest dependency in the roadmap. Without the HR data pipeline, lifecycle automation (item 17) is blocked. Item 16 is a cross-functional project between IT, HR, and Security with an estimated timeline of 2–4 months.

Presenting to the CISO — the executive communication

the CISO needs a 2-minute version. The structure is deliberate: open with the scope, lead with three numbers that reveal the gap, present three highest risks in business language, and close with the ask.

"We assessed the identity foundation — the layer that authentication, access control, and data protection all build on."

Three numbers:

• "1,006 identities in the tenant — not 810. The extra 196 are guests, applications, and service principals. Most are unmanaged."
• "151 stale identities — 15% of the total. Accounts for departed staff, expired application credentials, guest invitations from 3 years ago that nobody reviewed."
• "214 groups with 31 empty and 67 without an owner. We can't run automated access reviews on groups that nobody owns."

Three highest risks:

• "A legacy server we thought we decommissioned still has active credentials that can modify any user account in the cloud. The fix takes 2 hours."
• "98 stale guest accounts — 67% of all external access. Each one is a trust relationship with an outside organization that nobody monitors."
• "Four application integrations with expired credentials that are still somehow authenticating. We don't know how, and we need to investigate."

The ask:

• "The immediate fixes cost nothing — disabling accounts, deleting empty groups, removing stale invitations. We can do that this week."
• "The medium-term work — administrative boundaries, naming standards, licensing groups — is the architecture that enables automated governance. That's this quarter."
• "The long-term work — connecting the HR system to automate the employee lifecycle — requires a joint project with HR. That's next quarter."
• "Everything we build in Modules 2 through 14 — authentication, Conditional Access, privileged access, data protection, detection — builds on this foundation. The identity gaps we documented today are the gaps that will limit every subsequent control."

Before moving on, verify your understanding: Read MSA1-RISK-001. Explain in one sentence why a stale Kerberos key on a computer account is a HIGH-priority security risk, not a LOW-priority administrative cleanup. The roadmap puts HR provisioning in Tier 4 (long-term). Explain the dependency chain: what does item 16 enable that can't happen without it? Why can't lifecycle automation (item 17) start before the HR connection is established?

Reusable script — the commands from this sub assembled for operational use:

This sub IS the artifact. Copy the complete assessment into your architecture package at 01-identity/ne-identity-assessment.md. The assessment includes: census summary, 8 risk register entries, 3 ADRs, 8 additional findings, and the 4-tier remediation roadmap.

To produce this assessment for your own organization, run the queries from MSA1.1–1.10 against your tenant and structure the output in the same format. The assessment is evidence-based — every finding traces back to a specific Graph API query. The template is reusable: identity census → risk register → ADRs → additional findings → remediation roadmap → CISO summary.

Key diagnostic queries to run:

# Census (MSA1.2)
$cloudOnly = (Get-MgUser -All -Filter "userType eq 'Member'" -ConsistencyLevel eventual |
  Where-Object { $_.OnPremisesSyncEnabled -ne $true }).Count
$synced = (Get-MgUser -All -Filter "onPremisesSyncEnabled eq true" -ConsistencyLevel eventual).Count
$guests = (Get-MgUser -All -Filter "userType eq 'Guest'").Count
$apps = (Get-MgApplication -All).Count
Write-Host "Census: $cloudOnly cloud-only, $synced synced, $guests guests, $apps app registrations"

# Stale identities (MSA1.8)
$threshold = (Get-Date).AddDays(-90)
$stale = (Get-MgUser -All -Property SignInActivity -ConsistencyLevel eventual |
  Where-Object { $_.AccountEnabled -and $_.UserType -eq 'Member' -and
    ($_.SignInActivity.LastSignInDateTime -lt $threshold -or -not $_.SignInActivity.LastSignInDateTime)
  }).Count
Write-Host "Stale members (90d): $stale"

# Group sprawl (MSA1.10)
$groups = Get-MgGroup -All
$empty = ($groups | Where-Object {
  (Get-MgGroupMember -GroupId $_.Id -All -ErrorAction SilentlyContinue).Count -eq 0
}).Count
Write-Host "Groups: $($groups.Count) total, $empty empty"