Hello again. In the previous lesson, you learned to assess access changes through least privilege and separation of duties: first establish the approved need, inspect existing access, and avoid granting a role merely because someone asks for it.
Before deciding how to resolve an IAM ticket, a support analyst must decide what kind of ticket it is. A routine request follows one workflow; an access failure needs restoration and troubleshooting; a suspected compromise needs containment and security escalation. Misclassification can create real risk—for example, treating unexpected MFA prompts as an ordinary password-reset request can give an attacker time to keep using an account.
By the end of this lesson, you should be able to classify an IAM ticket as a service request, an access incident, or a security incident, explain the evidence behind the classification, and recognize when a ticket must be reclassified.
Suggested study time: about 40 minutes.
Classification is a routing decision
Ticket categories are not labels for reporting alone. They determine:
- the appropriate urgency and queue;
- which approvals and evidence are required;
- whether changes can be performed routinely;
- whether security containment must happen before normal troubleshooting;
- who needs to be informed.
Organizations use slightly different ITSM terminology. Always follow your employer’s ticket definitions and incident-response procedures. For this course, use the following practical taxonomy.
| Ticket type | Core question | Typical nature | Example |
|---|---|---|---|
| Service request | Is the user asking for a standard, defined service or approved access they do not yet have? | Planned and repeatable fulfillment | “Please add my approved account to the Finance Readers group.” |
| Access incident | Does a user who should have access currently lack it or fail to use it? | Unplanned interruption or degradation of authorized access | “My licensed, assigned account is denied access to Teams.” |
| Security incident | Is there evidence, or credible suspicion, of unauthorized use, compromise, or a threat to an identity? | Potentially adversarial; containment takes priority | “I received repeated MFA prompts that I did not initiate.” |
The important distinction is between requested access and failed access:
- A worker asking for an approved application assignment is usually making a service request.
- A worker who already has the approved assignment but cannot sign in is reporting an access incident.
- A worker who cannot sign in because an attacker changed their password, registered an unknown MFA method, or triggered risky sign-ins may be reporting a security incident.
A ticket’s first description is not always its final classification. A report such as “I cannot sign in” may begin as an access incident and be reclassified as a security incident when you find unusual locations, unfamiliar devices, repeated denied MFA prompts, or unauthorized account changes.
The safest rule is:
When credible compromise evidence exists, classify and handle the case as a security incident until security determines otherwise.
Do not allow a normal fulfillment workflow to delay containment.
Service requests: fulfill defined, authorized services
A service request is a formal request for a service the organization has already defined and agreed to provide. In IAM, this often means an approved request for access, an account action, or a standard identity service.
What is Service Request Management? - ServiceNow
Read ServiceNow’s overview to anchor the ITSM distinction between a standard request and an unexpected service failure. Its examples include password resets, but in IAM the surrounding security context still matters.
In the opening section, read from the definition through the discussion of common examples. Focus on the phrases “pre-defined,” “agreed-upon,” and “established pattern.” Then read the opening passage of the later section beginning the distinction. Notice that an incident involves an unplanned interruption or reduction in service quality, whereas a request seeks a normal service offering.
For IAM support, common service requests include:
- provisioning a new employee account from an approved joiner workflow;
- adding a user to an approved role-based group;
- assigning an approved license;
- granting a guest user access after sponsorship and approval;
- resetting a password through the approved process, when there are no signs of compromise;
- removing access after an authorized manager, HR, or application-owner request.
A request is not automatically routine merely because it uses a familiar phrase. “Reset my password” may be a standard request, but only after support follows the organization’s verification procedure and checks for warning signs. For example, an employee who says, “I am locked out because I approved an MFA notification by mistake” is not simply asking for a reset. That report contains possible compromise evidence.
What makes a request ready for fulfillment?
Before treating a ticket as a service request, establish that it contains enough information to use the normal workflow:
- A specific target identity: Which account is affected?
- A defined entitlement or action: What group, application, license, or account action is requested?
- An approved business need: Is there a manager, HR event, application-owner approval, or catalog workflow?
- An appropriate scope and duration: Does the request respect least privilege and any separation-of-duties rules?
- No credible security indicators: Is this a normal business change rather than an attempt to gain unauthorized access?
If a request is vague, overly broad, unapproved, or violates a control, it may remain a service request in the queue—but it is not ready to fulfill. Return it for clarification or route it to the appropriate owner. Do not silently convert an unapproved request into an access assignment.
Access incidents: restore access that should already work
An access incident is a specialized operational incident: the user should be able to access a resource, but access is failing or unexpectedly limited. Its immediate goal is to restore legitimate access safely.
The word should does a lot of work here. Verify the expected state rather than accepting the user’s assumption. A user saying “I should have access because Chris had it” is not proof of authorization. The role baseline, approved request, group membership, license status, or application assignment is the evidence.
Examples of likely access incidents include:
| Report | Initial classification | Why |
|---|---|---|
| “I am assigned the CRM license, but the CRM app says I have no access.” | Access incident | Expected access exists, but the service does not provide it. |
| “Our whole department cannot use the payroll application this morning.” | Access incident, potentially high priority | A shared service or shared authorization path may be failing. |
| “I was moved to Sales yesterday, and my approved Sales application access is still missing.” | Access incident | The approved mover change may not have completed or propagated. |
| “My account is locked after I entered an old password repeatedly.” | Access incident, initially | The immediate problem is denied access; investigate for security indicators before unlocking. |
At this stage, do not jump directly to a technical cause. Missing access may result from an absent license, a group-membership issue, an application assignment, a Conditional Access policy, synchronization delay, a disabled account, or a service outage. Later modules will cover how to diagnose those causes.
For classification, first preserve the useful facts:
- affected user and account;
- application, service, device, and resource involved;
- exact error message or screenshot, with sensitive content removed as appropriate;
- timestamp and time zone;
- whether the problem affects one person or multiple people;
- expected entitlement and its approval source;
- recent changes, such as a role move, device replacement, password change, or license assignment.
An access incident may be urgent. A payroll clerk blocked just before a payment deadline and an employee unable to access a low-impact training portal are both access incidents, but their business impact is different. Priority should reflect impact and urgency, not simply the word “incident.”
Security incidents: protect the identity before restoring convenience
A security incident involves suspected or confirmed unauthorized activity affecting an account, credential, MFA method, token, privileged role, or identity-related service. The priority shifts from routine fulfillment to limiting attacker opportunity, preserving evidence, and engaging the security process.
Microsoft Entra ID Protection provides risk detections and investigation evidence that commonly support this classification.
Investigate risk with Microsoft Entra ID Protection
Read Microsoft Learn’s investigation guidance to see how an identity-risk alert moves from initial triage through containment and a decision of safe, compromised, or dismissed.
Start with “Initial triage.” Read the triage guidance, focusing on sign-in logs, related activity, and the conditions that justify password reset, MFA, blocking, or session revocation. Next, in “Investigation and risk remediation framework,” read the investigation outcome and the numbered sign-in-log checks immediately following it. Finally, in “Investigate specific detections,” review the “Atypical travel,” “Password spray detections,” and “Leaked credentials detections” subsections. Focus on how location, application, device, IP address, user agent, and correlated account activity change the assessment.
The image below summarizes Microsoft’s remediation choices once risk has been detected.
Read this diagram carefully as a risk-response flow, not as a generic help-desk classification chart. It starts after a risk signal already exists. It also distinguishes actions that users may complete themselves—such as MFA or a secure password change—from actions that require an administrator.
Indicators that move a case into the security queue
A single unusual detail may be explainable; several related details are stronger evidence. Treat the following as security indicators requiring escalation or incident handling under your organization’s procedure:
- MFA prompts the user did not initiate, especially repeated prompts;
- an unrecognized sign-in, location, device, browser, application, or IP address;
- a risk detection for password spray, malicious IP activity, leaked credentials, suspicious browser activity, or anomalous tokens;
- an unexpected password reset, MFA-method registration, mailbox rule, application consent, or privileged-role change;
- reports of phishing, password disclosure, or a lost device containing active sessions;
- simultaneous or impossible travel sign-ins that the user cannot explain;
- multiple users receiving similar failures or MFA prompts from related IP addresses or at similar times.
A security incident does not require certainty that an attacker succeeded. IAM support frequently works with incomplete evidence. Credible suspicion is enough to trigger the security workflow, because a delay can allow further sign-ins, session use, data access, or privilege escalation.
The Microsoft guidance emphasizes checking the event against the user’s normal history: application, device, location, IP address, and user-agent information. It also recommends confirming the details with the user, but it warns that email or Teams may themselves be compromised. Follow your organization’s approved verification and out-of-band contact procedures; do not rely blindly on a message sent from the potentially compromised account.
Containment comes before ordinary troubleshooting
For a suspected compromised account, do not treat a password reset as the whole solution. Password exposure or active session theft can require broader action, such as password reset, MFA re-registration, session revocation, or account blocking. The exact authority and steps depend on your role and the incident procedure.
A first-line IAM analyst should generally:
- document the report and preserve relevant timestamps and identifiers;
- avoid making unapproved access changes;
- follow the authorized containment workflow or immediately engage the security team;
- avoid disclosing detailed investigation findings to an unverified requester;
- keep the security incident linked to any related access incident or service request.
For example, if a user reports being blocked from Microsoft 365 and you find that their account was blocked by a security control after a risky sign-in, the access problem is real, but the parent classification should be security incident. Re-enabling the account without security approval could undo containment.
A practical triage method
Use these three questions, in this order, for nearly every IAM ticket.
1. Is there a credible sign of compromise or unauthorized activity?
Look for risk alerts, unexpected MFA activity, suspicious sign-ins, unauthorized changes, credential exposure, or a pattern affecting other accounts.
- Yes or uncertain with meaningful evidence: classify as a security incident and follow the incident procedure.
- No: continue.
Security evidence takes precedence because normal account work can destroy evidence or restore an attacker’s access.
2. Is the user asking for a defined service or approved new entitlement?
Check the service catalog, approved lifecycle workflow, manager or owner approval, and role baseline.
- Yes: classify as a service request.
- No: continue.
Remember that “approved” means approved by the correct person and process. A colleague’s email saying “give them what I have” is not necessarily valid authorization.
3. Is authorized access unexpectedly unavailable?
Confirm that the identity should have access, then determine whether the service or authorization path has failed.
- Yes: classify as an access incident.
- No: gather clarification, or route the ticket for authorization or application-owner review.
This process can be summarized as a decision table:
| Evidence at triage | Classification | Immediate support posture |
|---|---|---|
| Approved request for a standard account, group, license, or reset; no compromise evidence | Service request | Validate authorization and fulfill through the standard workflow. |
| Existing approved access fails; no compromise evidence | Access incident | Verify expected access, assess impact, troubleshoot or route appropriately. |
| Unrecognized sign-in, MFA fatigue, leaked credential alert, suspicious account change, or phishing report | Security incident | Preserve evidence, contain or escalate according to procedure. |
| An ordinary request contains a security warning sign | Security incident | Do not fulfill it as routine until security handling is complete. |
| A risk alert is investigated and confirmed safe | Close or reclassify based on the remaining issue | A “safe” risk outcome is not automatically a service request. |
Worked classification examples
Consider how the same account action can belong to different categories depending on context.
Password reset
Case A: Priya verifies through the approved method and says she forgot her password. There are no risk alerts, unexpected MFA prompts, or unusual sign-ins.
This is a service request. Follow the approved reset process and record the action.
Case B: Priya reports that she received ten MFA prompts overnight and then lost access to her account.
This is a security incident. The access problem is not the primary issue; the MFA prompts suggest an attacker may have the password and is attempting to satisfy MFA.
Application access
Case A: An approved new starter requests access to the standard HR portal included in their assigned role.
This is a service request.
Case B: The same employee was already provisioned, assigned the required group and license, but receives “Access denied” when opening the portal.
This is an access incident. Collect the error, timestamp, account, and entitlement evidence, then investigate the authorization path.
Unfamiliar sign-in alert
Case A: Microsoft Entra flags atypical travel. The user confirms through the approved channel that they traveled to that location and used their normal managed device for a normal application.
The risk may be confirmed safe. It is not a security incident after validation, and it is not necessarily any kind of access ticket.
Case B: The user says they did not travel, the device is unfamiliar, and the alert shows a successful sign-in to an application they do not use.
This is a security incident. The user’s denial plus abnormal sign-in evidence supports immediate security handling.
Ticket notes should explain the classification
A useful first-line ticket note states not only what the user asked for, but why you selected the category. This makes handoffs faster and avoids a later analyst repeating the same fact-finding.
Service request example
Classification: Service request. User requested addition to the approved Marketing Analytics group. Manager approval and role-baseline requirement verified. No reported account-risk indicators or unusual sign-in activity. Assignment routed through the standard access workflow.
Access incident example
Classification: Access incident. User has an active account, required application license, and approved group membership but receives an authorization error in the CRM application. Impact currently limited to one user. Collected error text, timestamp, application name, and entitlement evidence. No compromise indicators reported. Routed to the application support owner for authorization-path review.
Security incident example
Classification: Security incident. User reported repeated uninitiated MFA prompts and an unfamiliar successful sign-in. Recorded timestamp, application, reported device status, and relevant sign-in details. No account-unblock or routine reset action performed outside the security workflow. Escalated to the security incident queue for containment and investigation.
Notice the difference in language:
- A service request note records authorization and fulfillment readiness.
- An access-incident note records expected access, actual failure, and technical evidence.
- A security-incident note records suspicious evidence, actions deliberately withheld, and the security handoff.
Key takeaways
A strong IAM support classification begins with the user’s expected state, the actual behavior, and any security evidence:
- A service request asks for a defined, approved service or new entitlement.
- An access incident means approved access should work but does not.
- A security incident involves suspected or confirmed unauthorized activity, compromise, or identity threat.
- Security evidence takes priority over routine fulfillment and ordinary troubleshooting.
- A ticket can be reclassified as evidence emerges; do not force an uncertain case into a routine category for convenience.
- Record the facts that justify the classification: approvals, expected access, errors, timestamps, scope, and suspicious indicators.
Next, you will focus on selecting an appropriate identity-verification method before performing an account action. That control is particularly important when a request appears routine but may actually originate from someone impersonating the user.
Can't find a good explanation? Sign up and we'll make it for you
Sign up