research
Measuring how much technician time goes to password resets
A sampling method for estimating the technician time consumed by password resets, separating self-service from assisted work and testing whether automation would pay for itself.
Use this benchmark to size repeatable IT work, set the review cadence, and decide what stays with the technical owner before assigning the workflow to an IT virtual assistant.
Research playbook
On this pageJump to section
Key stats
Key takeaways
Password resets feel too small to measure, yet they arrive in a steady stream that interrupts deeper work. A single reset may take four minutes, but the context switch, the identity verification, and the follow-up can make it far more expensive. This study describes a sampling method for estimating the technician time that resets actually consume. The output is a defensible annual estimate that a budget owner can compare with the cost of self-service or better identity controls.
Question and scope
This study asks how many technician hours per month are spent on password and account unlock work, and which user groups generate the largest share. The unit is one reset or unlock event, and the population is every such request closed during a declared month. The result describes that service desk and that period, not the performance of individual technicians. Freeze the definition and the month before exporting any data.
Include requests that arrive by phone, email, chat, and walk-up, because the channel changes the handling time but not the underlying work. Exclude planned password changes during onboarding and any identity project work. Record whether the request came from an employee, a contractor, or a shared account owner. The scope note should name the systems covered and the identity provider in use.
Define a password reset task
Define a reset as any interaction whose primary purpose is restoring access to an account by changing or unlocking a credential. A request that begins as a reset but becomes a broader access investigation should be split into two records if the system supports it. Record the start and end of the technician's active work, not just the ticket's open and close times. A ticket can sit for hours while the actual work takes minutes.
Include the identity verification step in the measured time, because skipping it would understate the true cost. Note whether the user was verified through a known phone number, a manager, or a video call. Exclude time spent waiting for the user to respond. The measure should reflect effort, not queue delay.
Build the ticket frame
Export the ticket identifier, the request type, the channel, the requester group, the assigned technician, and all timestamps. Add the resolution note so a reviewer can see whether the request was a simple reset or something more complex. Link duplicate requests for the same user and day. Reconcile the count with the service desk's monthly total and explain any difference.
Normalise the request types into a small set such as password reset, account unlock, multi-factor reset, and credential change. Keep the original type text so the mapping can be checked. Freeze the mapping before sampling and log any category added later. A category list that changes mid-study makes the comparison unreliable.
Sample and time the work
Select a random sample of reset tickets across channels and user groups, with a minimum of thirty cases for a first estimate. Time each case from the first technician action to the last, including verification and documentation. Use the ticket timestamps where they are reliable and a stopwatch observation where they are not. Record the method for each case so the estimate is transparent.
Ask two technicians to time a small overlapping set of cases independently. Compare their measurements and discuss any large difference. A gap often reveals that one person counted waiting time or skipped the verification step. Publish the agreed method with the estimate so the next study can repeat it.
Separate self-service from assisted resets
Count the resets that users completed through self-service separately from those that needed a technician. Self-service still has a support cost when users call for help, but the cost is different. Report the self-service adoption rate beside the assisted volume. A low adoption rate may be a usability problem rather than a training problem.
Check whether failed self-service attempts create a ticket after the user gives up. Those cases are hidden assisted resets and should be counted with the technician work. Review the identity provider's logs for reset attempts that did not complete. The gap between attempts and completions is often the most useful number in the study.
Estimate the annual load
Multiply the average handling time by the monthly volume and then by twelve, and present the result as a range rather than a single number. Show the assumptions about seasonality and headcount beside the estimate. A range with clear assumptions is more credible than a precise figure built on one quiet month. Check the volume against the prior quarter so a single busy month does not set the annual figure. Round the result to a level that reflects the uncertainty.
Convert the hours into a cost using the fully loaded rate the finance team already uses. Do not invent a salary figure or use a public average as if it were the company's own. If the rate is unavailable, report hours only and let the owner apply the cost. Keep the calculation in the report so the owner can change the rate without rebuilding the study. The purpose is a decision, not a precise accounting entry.
Compare with automation options
List the realistic options: self-service reset, stronger authentication, a managed identity service, or a change to the account lifecycle. Estimate the implementation effort and the recurring cost of each. Compare them with the measured reset load rather than with an industry claim. A tool that costs more than the work it removes needs a different justification. Ask the identity owner which options are technically viable before estimating effort.
Model the share of resets each option would actually eliminate. Self-service may remove simple resets but not account unlocks caused by a policy conflict. A single sign-on project may reduce one category while adding a new support path. Record the assumptions and the evidence behind each share. The comparison should make the trade-offs visible. If an option removes only a small share, it may still be worth doing for security reasons, but that should be a separate decision.
Report to the budget owner
Lead with the monthly hours, the annual range, and the user groups that generate the most work. Show the self-service adoption rate and the failed-attempt count beside the assisted volume. Add one example of a complex case that consumed far more time than a simple reset. Keep the technical detail in an appendix for the identity owner.
Ask for a specific decision, such as funding a self-service rollout or approving a policy change. Name the owner and the review date. If the decision is to accept the current load, record that choice and the evidence. A documented decision prevents the same conversation from restarting every quarter.
Limits and next use
The study measures recorded reset requests and the time technicians reported or were observed doing. It does not capture informal resets performed in a corridor or time lost by users waiting for access. It also cannot prove that a reset caused a delay in another project. State those limits so the estimate is read as a lower bound on the real cost.
Repeat the sample after any identity change and compare the same categories. If the assisted volume falls but the total hours stay flat, the remaining cases may be more complex. That is a different problem from a simple volume reduction. Record the date of the change so the two samples are not mixed. The next study should add the user's wait time and the failed self-service attempts as separate measures. A second month would show whether the load is seasonal or stable.
Pilot before you invest
Choose one user group for a self-service pilot and measure the same categories before and after. Define success as fewer assisted resets without a rise in failed attempts or security exceptions. Run the pilot long enough to include a month end and a holiday period. A short pilot can miss the moments when reset demand spikes.
Keep the manual process available during the pilot so a failed rollout does not block work. Record the reasons users still call for help and feed them back into the design. If the pilot succeeds, expand by group rather than by system. Review the pilot at a fixed date rather than waiting for a perfect result. The measurement method stays the same so the comparison remains honest.
Sources and next step
Use the NIST Cybersecurity Framework 2.0 and the CISA Cross-Sector Cybersecurity Performance Goals as primary references for the identity, asset, and vendor controls discussed here. The GAO data reliability guidance supports the sampling and verification approach used in these methods. Apply your own policies, contracts, and system documentation when adapting the method.
Compare this study with the asset record accuracy study and the account provisioning lead time study before combining them into one review cycle. If the measurement work is recurring and your technical owner can define the scope, review the service areas and contact ITVirtualAssistant to discuss a limited pilot.
Benchmark brief
What this research page must produce
A practical estimate for volume, review time, escalation rate, and assistant capacity.
A clear split between routine support, preparation work, and technical ownership.
What the measuring how much technician time goes to password resets data shows
Treat this as a planning benchmark, not a universal number. Compare the benchmark against your ticket volume, SaaS stack, documentation backlog, and support risk before assigning recurring work.
The useful output is a decision about capacity, not a static statistic. If the workflow is high volume and low judgment, an IT virtual assistant can absorb coordination and upkeep. If the workflow is low volume but high risk, keep it with the technical owner and use the assistant only for preparation, reminders, and documentation.
Workflow
Recommended operating workflow
Collect a baseline
Pull the last 30 to 90 days of examples related to measuring how much technician time goes to password resets, including completed work and unresolved exceptions.
Classify the work
Tag each item by routine admin, manager approval, technical decision, security risk, or vendor dependency.
Set the operating number
Use the median weekly volume and review time to decide how many assistant hours the workflow deserves.
Refresh the benchmark
Recheck the numbers quarterly so tool growth, new systems, and security requirements do not silently change the scope.
Decision rules
| Metric | Use it to decide | Manager action |
|---|---|---|
| Weekly volume | Whether the workflow is worth assigning as recurring assistant work. | Approve a weekly capacity target and backlog threshold. |
| Access sensitivity | Whether the assistant can work directly or only prepare review notes. | Set least-privilege permissions and removal dates. |
| Escalation rate | Whether the workflow is stable enough to delegate. | Rewrite the SOP when exceptions exceed the agreed threshold. |
Consolidated statistics
| Statistic | Figure | Source |
|---|---|---|
| Sample floor | 30 tickets | Study protocol |
| Time measures | 3 | Study protocol |
| Decision options | 4 | Study protocol |
Sources
- Digital Identity Guidelines: Authentication and Lifecycle ManagementAuthentication and credential management guidance relevant to reset design.
- NIST SP 800-53 Rev. 5Access control and identification controls for account management.
- CISA Cross-Sector Cybersecurity Performance GoalsPractical identity and access goals for small organizations.
- GAO Assessing Data ReliabilitySampling and evidence checks for operational estimates.
- Computer Support SpecialistsOccupational context for helpdesk and support work.
Measurement checklist
| Field | What to capture | Owner |
|---|---|---|
| Volume | Weekly request count, backlog age, and repeat issue patterns | Assistant prepares, manager reviews |
| Risk | Access level, customer impact, security sensitivity, and approval needs | Technical owner |
| Cadence | Daily, weekly, monthly, or quarterly review rhythm | Manager |
| Evidence | Sample tickets, logs, screenshots, and before-after examples | Assistant collects, owner validates |
| Escalation | Triggers, approval path, response time, and stop-work rules | Technical owner |
How to read the result
A good research page should leave the manager with a working number and a clear boundary: what the assistant can do every week, what the assistant can prepare for review, and what must never move without the accountable technical owner.
Source and refresh note
This planning page is dated for 2026 and should be refreshed quarterly as tool stacks, ticket patterns, and security expectations change.
How should teams use this benchmark?
Use it to define task volume, access limits, review cadence, and escalation rules before assigning work.
Get free benchmark review