Module 01 · Tier 1 · SOP-001
The single most common Tier 1 ticket. By the end of this module you'll understand why lockouts happen, how to execute resets safely, and how to document your work — exactly the way real IT environments do it.
// 1.1
Password resets are the single most common Tier 1 ticket in IT support. Understanding why they happen is just as important as knowing how to fix them.
| Cause | What It Means |
|---|---|
| Forgotten password | User simply cannot remember it — very common on Mondays or after vacations. |
| Expired password | Most organizations require password changes every 30–90 days. If the user misses the prompt, they get locked out. |
| Account lockout | Too many incorrect login attempts trigger an automatic lockout. This is a security feature, not a bug. |
| Caps Lock / typo | The most overlooked cause. Always check this first — it saves everyone time. |
| New device or browser | Saved passwords don't transfer between devices. The user may not remember what they set. |
// 1.2
Not all password resets are the same. The process changes depending on the account type. Knowing this before you start saves you from going down the wrong path.
Stored directly on the computer. Resetting requires the Settings app or a second admin account. Most common for home users and small businesses without a server.
Most CommonTied to an email address (Outlook, Hotmail, Live). Resets happen through Microsoft's website — you guide the user to account.microsoft.com. You cannot reset it directly.
Guide to WebManaged by a company server. Requires Tier 2 tools (Active Directory Users & Computers). If you see this on a Tier 1 ticket — escalate. Do not attempt without the right access.
Escalate → Tier 2// 1.3
Never reset a password without verifying who you're talking to. This is not a formality — it protects the user and the organization. Skipping identity verification is how social engineering attacks succeed.
Identity verification methods depend on your organization's policy, but common approaches include:
// 1.4
These are the words you'll hear in tickets, interviews, and real IT environments. Know them cold.
This is the exact procedure you follow for every local Windows password reset. Deviating from this order creates risk and inconsistency.
// step-by-step procedure
Ask the user's full name and one confirming detail (email on file, employee ID, etc.) before taking any action.
Ask: "Is this a personal computer or a work computer? Is it connected to a company network?" This determines your next steps.
Navigate to the password reset screen.
Windows key → Settings → Accounts → Sign-in options → Password → ChangeCreate a simple, temporary password (Example: TRH@Reset1). Do NOT make it permanent or reuse old passwords.
Ensure the user is required to create their own password on next login. This is a security requirement — not optional.
Have the user log out and log back in using the temporary password. Watch them complete the password change before closing the ticket.
Write the resolution in your ticket notes. Include: date/time, account type, and outcome. Mark ticket resolved.
// escalation criteria
Stop and escalate if any of the following are true:
// quick reference
// 3.1 — scenario-based practice
Read each scenario and decide what action to take. These mirror real Tier 1 situations.
A client calls and says: "I can't log in. I've been trying since this morning and now it says my account is locked." You check and confirm this is a local Windows account on their personal laptop.
A user says: "My company email password stopped working." You start walking them through Settings → Accounts when they mention, "Oh, we use Outlook through our company server."
Someone contacts you claiming to be a manager and asks you to reset the password on an account that "belongs to one of my employees." They can't verify the employee's identity themselves and seem impatient.
// 3.2 — documentation practice
After completing a password reset, every tech at The Rarest Heart writes a ticket note. Use the format below and write the ticket note for Scenario 1.
| Field | Your Entry |
|---|---|
| Date / Time | |
| Account Type | |
| Issue Reported | |
| Identity Verified? | |
| Steps Taken | |
| Resolution | |
| Escalated? |
// 3.3 — interview preparation
Employers at every level ask some version of these questions. The model answers below show the framework — put it in your own words.
"Tell me about your process when a user is locked out of their account."
Start with identity verification → explain account type assessment → walk through your reset steps → mention forced password change → end with documentation.
"How do you handle a password reset when you're not sure what kind of account it is?"
I ask the user two questions: is this a personal or work device, and is it connected to a company network? That tells me whether I'm dealing with a local account, a Microsoft account, or a domain account — each one has a different reset path.
"What do you do when a reset request seems suspicious?"
My first responsibility is to protect the account owner. I follow the identity verification policy — if I can't verify the requester's authority, I don't proceed. I document the attempt and flag it to a supervisor. Security policies exist for exactly this reason.
// module completion checklist
Check each item before marking this module complete.
// what comes next
Every module follows the same structure. The further you go, the more you'll realize you already know.