Assess the Sophos ITDR Identity Risk Score safely

The Identity Risk Score assesses the risk of an individual user identity on a scale of 0 to 10. It combines the likelihood of a security incident with the potential impact of a compromised identity. A high value is therefore a prioritization signal, but neither proof of compromise nor an automatic instruction to act.

For daily triage, sort by Risk Score in descending order, review the Contributing factors of the highest-ranked identities, and address open critical or high findings and directly actionable Security Factors first. The numerical value alone is not enough for a sound decision.

Where to find the Risk Score

Sophos ITDR shows the value in three places:

• Under My Products > Identity > Directory > Identities, the table contains the Risk Score column. In card view, the value appears at the top right of each card.
• After selecting an identity, Identity Details > Summary shows the panel Risk Score with Current score, Contributing factors and the time of the last calculation.
• Under My Products > Identity > Identity Overview, the Top 5 Risky Users widget combines high scores with open findings. Each entry shows the identity name, open findings by severity, and current score.

For a complete check, use Directory > Identities > Identity Details > Summary. The Overview widget is a quick prioritization aid and does not replace the detail view.

Interpret the five score bands correctly

The band boundaries are fixed, but factor weighting is not. You therefore cannot calculate an exact score from a list of attributes. Two users with the same role may have different values because of their MFA status, administrative roles, guest status, findings, sign-in location, or previous alert and investigation activity.

A low score is not a guarantee of safety either. It reflects how the model evaluates the signals currently available. Missing telemetry, an incomplete baseline, or a finding discovered later can change the classification.

Which identities receive a score

Risk Scores are currently calculated for Active user identities from Microsoft Entra ID and on-premises Active Directory. No Risk Score appears for identities whose identity-provider status is Deleted or Disabled. The score currently excludes application and service-principal identities.

This scope matters when making comparisons: an identity without a value is not automatically low-risk. First check its identity type and status at the connected identity provider. A missing value is a diagnostic indicator only when the identity is an active user identity.

Distinguish Security Factors from Profile Factors

The Contributing factors panel distinguishes two effects:

• Factors raising Risk Score shows factors that increase the current value.
• Factors lowering Risk Score shows factors that lower it.

Within both groups, Sophos distinguishes between Security Factors and Profile Factors.

Security Factors: Act here first

Security Factors describe security status, configuration, and known activity. Factors that can be influenced directly include:

• missing MFA;
• MFA without a passwordless method;
• open findings, referred to in the panel as Identity Exposures;
• administrative or privileged directory roles;
• guest status;
• active credential leaks;
• a large number of linked email addresses.

Other signals include a hybrid account synchronized from an on-premises directory and historical alert and investigation activity. Neither can be eliminated by a single change to the identity: hybrid status describes the directory architecture, while the history reflects previous alerts and investigations.

Factors that lower the score include enforced MFA, a passwordless MFA method, a history without relevant alerts or investigations, remediated findings or findings marked Dismissed, removal of unnecessary admin roles, and fewer linked email addresses. The model weights these signals; this list is not an additive points table.

Profile Factors: Context instead of repair goal

Profile Factors refer to identity attributes, for example:

• Department;
• Job Title;
• City;
• Employee Type;
• existing or missing manager;
• VIP monitoring, visible in the panel as High-value identity, prioritize monitoring.

These characteristics can increase or decrease the score, but are not usually security misconfigurations. Department, job function, or location should not be changed just to reduce a number. Incorrect or outdated directory data may be corrected; accurate profile data should remain and serve as risk context.

Empty fields such as Department, Employee Type or Job Title are not necessarily neutral. The model can take into account missing information based on similar identities and derive risk context. Therefore, complete and correct directory data provides a more precise context, but does not guarantee a specific score or its direction.

According to Sophos, active credential leaks, hybrid status, and VIP monitoring can raise the score but do not contribute to lowering it. This does not mean that VIP monitoring should be removed: the label deliberately makes a valuable identity more visible and must not be removed merely to improve the score.

What No data means

If a section of the Risk Score panel shows No data, no factors are listed in that specific category. This does not automatically mean that no data exists for the identity as a whole or that its integration is faulty.

So check one by one:

1. Is No data only under a sub-area such as the lowering Profile Factors?
2. Are there any factors in the other groups?
3. Is there a plausible time at the bottom of the panel for the last calculation?
4. Is the identity an active user identity?
5. Are the expected directory attributes and findings available in their respective locations?

Check the integration’s data delivery only if several expected areas are missing, the calculation time is implausible, or an active user identity receives no score at all.

Consider baseline and calculation cycles

For a new tenant or newly added user identity, ITDR first builds a behavioral profile. Many new identities can therefore remain in the Informational band for up to 30 days. This period is a possible baseline-building phase, not a waiting period during which findings may be ignored: open findings can produce a higher score even for a new identity.

Scores undergo a daily assessment cycle. A recalculation can also occur when ITDR observes an account change or a finding changes. A score can shift from one day to the next even without a visible directory change because the model includes historical alert and investigation activity and adjusts its weighting over time.

After remediating a finding, an updated value may appear shortly afterward. Remediated findings continue to affect the score with reduced weighting until the next daily scoring cycle; the full effect is therefore visible only in the following day’s score. These two mechanisms provide neither a guaranteed update time nor an exactly predictable point change.

Limitations of the ML model

The Risk Score comes from a machine-learning model, not a fixed checklist. Factors are not weighted equally, so the same visible factors do not necessarily produce the same score or the same change for two identities.

According to Sophos, the model is trained on aggregated behavioral and account signals from the ITDR customer base; an identity’s score is calculated using current data from its own tenant. Clear operational limits nevertheless remain:

• The score indicates priority, not the cause of an incident. Establishing the cause requires findings and further investigation results.
• A high value does not prove compromise, and a privileged identity with weak posture can be ranked high even without observed suspicious activity.
• A low value does not prove that the identity is safe.
• The factors displayed are the operational explanation for this identity, but not a formula from which the numerical value can be reproduced.
• A score change alone is not proof that a measure was technically successful.

The safe approach is therefore to read the cause in the panel, verify the underlying configuration or finding separately, and only then use the score as an additional indicator of effect.

Safely prioritize identities

Sorting by the highest numerical value alone can overlook valuable context. Use the following workflow:

1. Under Directory > Identities, sort by Risk Score in descending order.
2. Open Identity Details > Summary for the highest-ranked identities.
3. Under Contributing factors, check if there are open critical or high Identity Exposures.
4. Prioritize critical and high findings and active credential leaks over profile context alone.
5. When urgency is equal, examine privileged, administrative, and VIP-monitored identities first because of their potential impact.
6. For each measure, record the initial value, band, timestamp, and specific score-raising factor.
7. Only fix the underlying cause, not optimize the score cosmetically.

Typical safe measures include remediating the root cause of critical and high findings, enforcing MFA and, where possible, providing a passwordless MFA method. Handle active credential leaks through the approved incident process. Revoke unnecessary admin roles and remove linked email addresses that are no longer required; where appropriate, convert guest accounts to managed accounts. Every change requires the approvals customary in your organization and a separate functional check.

Validate the effect after a measure

A robust control separates technical effectiveness from model response:

1. Record the initial state: Note the identity, Current score, band, Factors raising Risk Score, open findings, and timestamp of the last calculation.
2. Resolve cause: For example, actually enforce MFA in the identity provider or remove an unnecessary role after approval. Do not change several independent factors at the same time if the effect is to remain traceable.
3. Check the technical status: Check in the system that the change is effective. The Risk Score is not the primary proof of this.
4. Check ITDR data: In Identity Details > Summary confirm that the relevant factor or finding is displayed correctly after processing.
5. Wait for recalculation: Check the timestamp at the bottom of the panel. After remediating a finding, check the short-term update and allow for the next daily cycle before assessing the full effect.
6. Compare the result: Compare the score, band, and factors with the initial state. Expect the remediated cause to be represented consistently, not a predetermined score.
7. Address remaining causes: If the value remains high, review the remaining Security Factors, open findings, and then the profile context.

Validation is complete when three points are confirmed: the technical measure is effective, ITDR correctly displays the underlying factor, and the next score calculation is plausible given the remaining signals.

Troubleshooting unexpected scores

The score suddenly rises sharply

First open the detail view and look under Factors raising Risk Score for new Identity Exposures, especially critical or high findings. Then compare MFA, roles, guest status, credential leaks, and the calculation time. A jump does not prove an incident, but a critical or high band requires prompt investigation.

The score does not decrease as expected after the correction

Check that the change is actually effective in the relevant identity provider and that ITDR already shows the updated factor. A remediated finding may retain reduced residual weighting until the next daily cycle. If the score remains elevated afterward, examine the other factors; do not expect a fixed point reduction from a single measure.

The score changes without a directory change

This is not automatically an error. Daily recalculation and the aging of alert and investigation activity can change the value. Document the old and new scores, both calculation times, and the displayed factors. Investigate the integration further only if the data conflicts or a timestamp is implausible.

An active user identity has no score

First, confirm the Active status at the identity provider, the User identity type, and the assignment to the connected Entra ID or Active Directory source. Then check whether other current attributes of the same identity appear in ITDR. Deleted, Disabled, applications, and service principals are outside the current score scope.

Many new identities remain Informational

Check the onboarding date and open findings. This can be normal during the possible baseline phase of up to 30 days. Open findings must still be addressed immediately. If many identities remain in the Informational band after 30 days, check the calculation time, displayed factors, and data freshness to determine whether ITDR is processing the expected signals.

If an unexpected state cannot be explained, record the identity name without unnecessary personal data, its source, status, score, band, visible factors, calculation time, relevant finding IDs, and the time of the last approved change. These details enable targeted escalation without inferring an unproven cause from the score itself.