Temporary Access Codes Are How Exceptions Stay Temporary

By Raymond Todd Blackwood, President of QuickLaunch

Move-in week is the identity business at full volume. New students claiming accounts in an orientation line. Returning students discovering that the phone they enrolled in multi-factor authentication (MFA) with last spring got traded in over the summer. Transfer students, dual-enrollment sophomores, adjuncts hired Friday and teaching Monday. Out in Boulder this fall, the university IT shop staffed in-person help tables for the first seven days of classes just to walk people through sign-in and MFA. Nobody does that for fun. They do it because the first week of a semester is where authentication policy meets the messy reality of people.

And somewhere in that line is the case your architecture diagram never shows. A student whose MFA device is simply gone. Not misplaced. Gone. She is standing at the helpdesk with a drop/add deadline tonight, a registrar hold to clear, and no way to complete the prompt your access policy insists on. What happens in the next five minutes is your identity strategy. Not the version in the deck. The real one.

So let me answer the question under this column's title directly. Temporary access codes are short-lived credentials a helpdesk issues so a verified user can get through MFA when their registered factor is unavailable. QuickLaunch ships this as a built-in capability: an authorized administrator generates a secure code, sets a validity window measured in hours, and the code expires on its own, with every generation logged for audit. That is the exception pattern done right, and it is deliberately narrow. The code gets the student to her deadline without anyone switching MFA off for her account. What no product can do, mine included, is prove that the person asking for the code is the person she claims to be. That step belongs to your institution, and it has quietly become the most attacked step in the entire flow.

Last week I wrote about external authentication methods and who holds the keys to your campus. This week is the harder question. What do you do when someone walks up to the counter and says they lost theirs?

The Exception Path Is the Attack Path Now

Read the incident reports from the last few years and a pattern stands out. Attackers stopped picking the lock and started calling the locksmith. CISA and the FBI maintain a joint advisory on a criminal crew that, in the agencies' own words, targets large companies and their contracted IT help desks. The updated advisory describes actors who pose as employees to convince helpdesk staff to reset passwords and transfer MFA to a device the attacker controls. They rehearse. Early calls probe how the reset procedure works. Later calls exploit it.

The receipts are not subtle. A casino operator, MGM Resorts, watched a headline breach unfold after attackers reportedly impersonated an employee they found on LinkedIn and simply called the helpdesk. The British retailer Marks and Spencer traced a ransomware event to a third-party service desk that was socially engineered into resetting an employee password. And this summer, security reporting documented attackers using AI-cloned voices to impersonate IT staff at major Wall Street firms, calling helpdesk agents directly and pressuring them into resetting credentials in real time. They do not phish the login page anymore. They phone the person who can bypass it. The exception path is the attack path.

Higher ed is not a spectator here. Your helpdesk during drop/add week is staffed for volume, often with student workers, exactly when the pressure to move fast is highest. UC Santa Cruz publicly warned its campus about phishing campaigns built to take over student accounts and redirect financial aid refunds. The federal government has spent two years tightening identity verification around student aid for the same reason. The United Kingdom's National Cyber Security Centre gave the plainest advice of the bunch: review your helpdesk password reset process, specifically how the helpdesk authenticates the person before resetting anything. That sentence is the whole game.

Verify the Human Before You Mint the Key

The institutions that handle this well share one discipline, and it is not a product. The University of Florida's IT knowledge base says a student who lost their MFA device gets a temporary passcode after the helpdesk verifies a government-issued ID by video conference or in person. UW-Madison's process routes the same situation to an agent who verifies identity before issuing a code. Neither flow trusts a voice on the phone, which matters more every month now that a convincing voice costs an attacker nothing.

The standards agree. NIST's current digital identity guidelines treat account recovery as an authentication event with its own rules: a short list of sanctioned recovery methods, mandatory notification to the user whenever recovery happens on their account, and, at the assurance level most campuses target, a requirement for two independent recovery signals or a fresh run of identity proofing. Microsoft's deployment guidance for phishing-resistant authentication starts at the same place, putting identity verification in front of credential issuance, not behind it. Prove the person. Then mint the key. Never the other way around.

Here is where I name what our platform does and does not do. QuickLaunch makes the minting itself hard to abuse: temporary access codes are restricted to authorized helpdesk administrators, the option does not even appear until the administrator has enabled two-factor authentication on their own account, and every code generation lands in the audit log. That is real protection against a quiet bypass. But the verification script, the callback to the number on record, the ID check, the rule that nobody mints a code on the strength of a voice alone? That is policy, and policy is yours. A locksmith can cut a spare key with a serial number and a paper trail. He still should not cut it for whoever sounds confident at the counter.

A Good Code Carries Its Own Clock

The second discipline is time, and the whole industry has converged on the same answer: hours, not weeks. QuickLaunch temporary access codes live inside a validity window you set, measured in hours, and expire on their own when it closes. Microsoft's equivalent pass defaults to a single hour. Duo's bypass codes, by default, die after one use or one hour, whichever comes first. NIST is the strictest of all: a recovery code sent by text message or voice call should be trusted for ten minutes, and one sent by email for a day. I put a prediction on record this spring that one-time codes over SMS and email would start being treated as a risk rather than a control. A federal guideline that trusts a texted code for ten minutes is not a landing for that prediction, but it is the wind blowing in exactly that direction.

There is a quieter lesson in the fine print, and credit to Microsoft for documenting it against their own feature: expiration does not retroactively end sessions that were established while the code was valid, so session lifetime needs its own policy for exception sign-ins. Duo's documentation carries a cousin of the same warning, noting a bypass code can seed a remembered-device session that outlives the code itself. The clock has to cover everything the code opens. Not just the code.

The Exception List Is Where Ghosts Get Born

Now the part your auditor will find before you do. The dangerous exception is rarely the code with a clock on it. It is the standing exception that nobody is counting. Microsoft's own planning guidance for access policy says to use exclusions sparingly and to add excluded users back as soon as possible, and recommends recurring access reviews on exclusion groups precisely because people who qualified for an exception last year quietly stop qualifying and stay excluded anyway. Duo will let an administrator configure a bypass code that never expires with unlimited reuse, and its admin panel flags exactly that configuration as weak. Even the break-glass account, the one permanent exception every auditor accepts, comes with mandated hygiene in Microsoft's guidance: validate it at least every 90 days, monitor every sign-in, run a post-mortem after every use.

Sit with that last one. If the most sanctioned exception in the industry earns a quarterly checkup, your pile of ad-hoc ones, the MFA exclusion group left over from an old rollout, the bypass code from an incident nobody remembers, has earned at least the same. I have spent months in this column on ghost accounts, the identities that outlive their people. Exceptions age exactly the same way. The student graduates. The exclusion stays. Next week this column takes on the bigger version of that problem, what to do when students disappear or graduate, and the exception list is the on-ramp to it.

So treat every exception as a loan, not a gift. The working session fits in an afternoon, and it is four lines on a whiteboard. Who is allowed to mint a temporary access code. What they must verify before minting one, in writing, with no voice-only path. The longest clock you will tolerate, in hours. And who reads the exception list every month, with the standing authority to shrink it. Temporary is a policy outcome, not a product feature. The campuses that write those four lines down will walk into audit season, and the next clever phone call, already knowing how the story ends.

Take the Next Step

Primary: Bring your exception list to the On-Ramp Lifecycle Audit, QuickLaunch's identity lifecycle assessment. Current capability detail on temporary access codes lives in the release notes and on the identity and access platform page.

Secondary: Follow the weekly column on the QuickLaunch blog. Next week: deprovisioning strategies for when students disappear or graduate.

FAQ

What is a temporary access code?

A temporary access code is a short-lived credential that a helpdesk or identity administrator issues to a verified user who cannot complete multi-factor authentication because their registered device is lost, replaced, or unavailable. In the QuickLaunch platform, an authorized administrator generates the code, sets a validity period between 1 and 24 hours, and the code expires automatically, with every generation recorded in the audit log.

How long should a temporary access code last?

As short as the situation allows, measured in hours. QuickLaunch supports validity windows from 1 to 24 hours with automatic expiration. Microsoft's Temporary Access Pass defaults to one hour, and Duo bypass codes default to a single use or 60 minutes. NIST SP 800-63B-4 caps trust in a recovery code sent by SMS or voice at 10 minutes and by email at 24 hours, so a same-day window is the defensible norm for campus use.

What should a helpdesk verify before issuing a temporary access code?

The helpdesk should verify the requester's identity through a channel stronger than the phone call itself: a government-issued ID checked over video or in person, as the University of Florida requires, or a callback to contact information already on record, combined with automatic notification to the account holder whenever a code is issued. NIST SP 800-63B-4 requires notification on every account recovery event, and no code should ever be issued on the strength of a familiar-sounding voice, because attackers now clone voices convincingly.

Are temporary access codes safer than standing MFA exceptions?

Yes. A temporary access code expires on its own, so the exposure ends even if nobody remembers to close it, while a standing MFA exception, such as a policy exclusion group or a never-expiring bypass code, stays open until someone finds it. Microsoft advises using policy exclusions sparingly and reviewing them on a recurring basis, and Duo flags never-expiring bypass codes as weak configuration. Time-boxed codes plus a monthly review of any remaining exceptions is the defensible pattern.

References

• OIT summer updates 2026 - University of Colorado Boulder, Office of Information Technology. https://oit.colorado.edu/news/oit-summer-updates-2026
• Scattered Spider (Joint Cybersecurity Advisory AA23-320A, updated July 2025) - CISA, FBI, RCMP, ACSC, NCSC-UK. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
• MGM Resorts service desk hack - Specops Software. https://specopssoft.com/blog/mgm-resorts-service-desk-hack/
• Marks and Spencer breach linked to Scattered Spider ransomware attack - BleepingComputer. https://www.bleepingcomputer.com/news/security/marks-and-spencer-breach-linked-to-scattered-spider-ransomware-attack/
• Thwarting the AI vishing attacks that targeted Point72, Citadel, Two Sigma and more - Security Boulevard. https://securityboulevard.com/2026/08/thwarting-the-ai-vishing-attacks-that-targeted-point72-citadel-two-sigma-and-more/
• Student direct deposit fraud phishing attacks - UC Santa Cruz. https://news.ucsc.edu/2026/01/student-direct-deposit-fraud-phishing-attacks/
• Incidents impacting retailers - UK National Cyber Security Centre. https://www.ncsc.gov.uk/blog-post/incidents-impacting-retailers
• I have lost access to my Duo device - University of Florida Information Technology. https://ufl.teamdynamix.com/TDClient/33/IT-Portal/KB/Article/515/
• MFA-Duo: Lost or forgotten device - University of Wisconsin-Madison KnowledgeBase. https://kb.wisc.edu/iam/page.php?id=81983
• NIST Special Publication 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, Section 4.2 Account Recovery - NIST. https://pages.nist.gov/800-63-4/sp800-63b/events/
• Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID - Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication
• QuickLaunch Release Notes - QuickLaunch. https://quicklaunch.io/release-notes/quicklaunch/
• Configure a Temporary Access Pass in Microsoft Entra ID - Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass
• Duo Administration: Manage Users (bypass codes) - Cisco Duo. https://duo.com/docs/administration-users
• Plan a Conditional Access deployment - Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access
• Manage emergency access admin accounts - Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access

Raymond Todd Blackwood is the President of QuickLaunch and writes about identity, agentic AI, and the messy reality of higher-ed IT. #ItsExistential