Skip to main content
Version: Angophra

Account Reports

Menu path: Observe → Deep Dive → Accounts
URL: /en/insights/dashboard/identity/accounts

Purpose​

The Account Reports page is the most comprehensive view of the individual directory account population in your environment. It lets you interrogate accounts from multiple angles: their state (enabled vs disabled), their type, their activity patterns, their lifecycle issues, and whether they are correctly matched to people.

This page is where you surface the health of the accounts themselves - independent of the people who own them. It shows the good (accounts that are correctly provisioned and actively used), the bad (accounts that are stale, inactive, or not matched), and the ugly (orphaned accounts and accounts that have been used after expiry).

The page includes filters for Account Type and Data Source, allowing you to narrow your analysis to specific directories or account categories.

Charts and Reports​

Accounts by State​

Chart type: add example --> Summary/KPI tiles
What it shows: A count of accounts broken down by their current state, as of the most recent successful sync run. Typically shows Enabled, Disabled, and other states.

Why it matters: This is the baseline inventory of your account population. The ratio of enabled to disabled accounts is a key governance metric - too many enabled accounts relative to your active workforce may indicate poor lifecycle management (accounts not being disabled when people leave). A "View Last Run" link allows you to see exactly when the data was last refreshed.

Account Types by DataSource​

Chart type: add example --> Grouped bar chart
What it shows: The count of each account type within each data source. For example, how many Productivity, Finance, Admins, Contractor, Breakglass, M42, etc. accounts exist in each directory.

Why it matters: This chart gives you visibility into the composition of each directory. Key things to look for: unexpectedly high numbers of admin accounts, test accounts that have proliferated, or account types that should not exist in certain directories (e.g., test accounts in a production Entra ID tenant).

Account Status By DataSource​

Chart type: add example --> Stacked bar chart
What it shows: For each data source, the split between enabled and disabled accounts.

Why it matters: A healthy environment should have a relatively small proportion of disabled accounts that are recently disabled (pending deletion) and a much larger proportion of active enabled accounts. A large number of enabled accounts in a data source with no recent activity is a warning sign.

Inactive Accounts​

Chart type: add example --> Bar chart
What it shows: Accounts that have not been used in the last 45 days, broken down by data source and account type.

Why it matters: Inactive accounts are a security risk - they represent credentials that are valid but not being actively monitored. An attacker who compromises an inactive account may go undetected for longer because there is no "normal" baseline of activity to compare against. Inactive accounts in privileged account types (Admins, Breakglass) are particularly concerning.

What to do: Investigate inactive accounts by type. Admin accounts that have been inactive for 45 days should be reviewed - either the person is no longer performing admin duties (and the account should be disabled) or there is a legitimate reason for the inactivity. Standard user accounts that are inactive may belong to people on leave, or the accounts may no longer be needed.

Dormant Accounts​

Chart type: add example --> Bar chart
What it shows: Accounts that have not been used in the last 90 days, broken down by data source and account type.

Why it matters: Dormant accounts (90+ days of inactivity) represent a stronger signal that something is wrong. At 90 days, most legitimate periods of absence (holiday, short-term leave) would have ended. These accounts are strong candidates for disablement, especially if the associated person is no longer with the organisation or no longer needs the account type in question.

What to investigate: Cross-reference dormant accounts against your HR system to verify the person's current employment status. Dormant admin accounts in particular should be disabled immediately if the person is no longer performing admin duties.

Unused Accounts​

Chart type: add example --> KPI/bar chart
What it shows: Accounts that have never been used (no logon recorded) but are currently enabled.

Why it matters - this is a key finding in many environments. Unused-but-enabled accounts represent credentials that exist, have never been used, and therefore have no security monitoring baseline. They may be: accounts created for people who never started (pre-joiners who did not arrive), accounts created by bulk provisioning processes that were not needed, or test accounts left behind. Each unused enabled account is an attack surface that serves no business purpose.

What to do: Review unused accounts against your HR records. If the person has not started yet (pre-joiner), this is expected. If the person is active and has never logged in, investigate why - there may be an onboarding issue. If there is no person associated, the account should be disabled and scheduled for deletion.

Orphaned Accounts​

Chart type: add example --> Bar chart or KPI
What it shows: Accounts in directories that have no matched identity in Apporetum.

Why it matters: Orphaned accounts are one of the most important hygiene metrics in IAM. They represent accounts that exist in your directories but cannot be traced back to a known person. This could mean: the person left and their accounts were not cleaned up, the account was created manually outside the normal provisioning process, or there is a data matching failure in the identity resolution layer.

With 5,204 orphaned accounts in the example environment, this is a significant finding - it means thousands of accounts exist in directories with no owner accountability in the IAM system.

What to do: Work through orphaned accounts methodically. Start with accounts in privileged categories. For each orphaned account, determine: does a person exist in HR who should own this? If yes, remediate the matching. If no, when was the account last used? Old, unused orphaned accounts should be disabled immediately.

Post Departure Activity​

Chart type: add example --> Bar chart
What it shows: Accounts that have been used after their account expiry date, broken down by data source.

Why it matters: This is the most serious account-level finding. Post-departure account activity means someone (or something) used an account after it should have been deactivated. This is a potential security breach indicator and must be investigated.

The Accounts Table​

The comprehensive accounts table provides detailed filtering and sorting capabilities. Key columns include:

  • Display Name - The account's name and email
  • Account Type - The categorisation of the account (Productivity, Admins, Contractor, etc.)
  • Object Type - Member or Guest (in Entra ID terms)
  • Last Logon - The most recent sign-in date
  • Status - Active, Inactive, Dormant, etc.
  • Enabled - Whether the account is currently enabled

Filters available include Account Type, Data Source, Status, User Type, and whether the account is Enabled.

Tips for using the table​

Use the "Account Type" filter to focus on privileged accounts (Admins, Breakglass, M42 Admin) when doing a security review. Use the "Status" filter to pull up only Inactive or Dormant accounts for lifecycle remediation work. Combine "Orphaned" filter with account type to prioritise which orphaned accounts need the most urgent attention.