Previously in the series: Why the Help Desk Is the Most Exploitable Identity System You Own  

Most organisations believe identity risk is mainly a question of strong onboarding, MFA, and modern access controls. That model is now outdated. The centre of gravity has shifted to identity re-establishment: recovery, resets, exception approvals, and urgent access restoration often handled through operational teams and third parties. 

This is why many identity incidents now look “legitimate” in hindsight: controls worked, processes were followed, and logs appear clean, yet the wrong identity was confidently re-granted access. This is not an awareness problem. It’s a scale problem, identity decisions are occurring at volumes traditional identity architectures were never designed to secure. 

1) The Market Signal: Identity compromise is now identity-centric 

Over the last few years, the most consistent theme across major threat reporting is that attackers increasingly win by acquiring or abusing identity rather than “breaking in” through sophisticated technical exploits. 

• Verizon’s DBIR continues to show credential abuse and phishing as major drivers of breaches and initial access across common attack patterns. [1] 
• Microsoft reports identity attacks at massive daily scale, with password-based attacks comprising the overwhelming majority of observed identity attack activity. [2] 
• Mandiant reports stolen credentials as one of the most common initial infection vectors observed in incident response investigations (and rising). [3] 
• In Australia, ASD reporting highlights techniques like phishing and compromised accounts as top observed techniques across incident reporting. [4] 
• OAIC breach reporting continues to document malicious attacks as key drivers of notifiable data breaches, reinforcing that identity-related intrusion remains central to privacy exposure. [5] 

None of this should surprise a CISO. 

What is being underweighted is where identity compromise is increasingly being operationalised inside organisations: the downstream moments where trust is re-granted under pressure. 

2) The shift most programs haven’t modelled: Identity is being re-established, not just authenticated 

Identity programs have historically been structured around a small number of “high assurance” events: 

• onboarding / joiner identity proofing 
• initial credential issuance 
• baseline authentication and access policies 
• privileged access controls 
• session enforcement 

That architecture assumes a simple lifecycle: verify → authenticate → authorise → monitor. 

But modern operating models have quietly rewritten the lifecycle: 

verify → authenticate → recover → reset → exception → re-grant trust → repeat 

In large enterprises, these re-establishment moments happen continuously: 

• locked accounts 
• password resets 
• MFA re-issuance / device replacement 
• urgent access reinstatement 
• privilege changes and temporary elevation 
• exceptions when controls block productivity 

This isn’t rare. It’s operational. 

And it is precisely where attackers prefer to operate, because human decision pathways are easier to exploit than hardened technical enforcement. 

Verizon, Microsoft, and Mandiant all reinforce the same macro reality: identity compromise and social engineering are persistent, scaled, and economically efficient for attackers. [1][2][3] 

3) Why the help desk matters (even if it isn’t the only issue) 

The first article in this series focused on the help desk because it is the most visible example of a broader phenomenon, operational functions becoming identity authorities. 

Help desks and service operations can intentionally or not, become the place where attackers convert partial knowledge into full access: 

• “I’m locked out” 
• “I changed phones” 
• “I’m travelling and can’t access MFA” 
• “I need urgent access — CEO is waiting” 
• “I’m a contractor starting today; onboarding didn’t work” 

These are the moments where identity assurance needs to be highest, because the decision often re-creates the conditions for compromise. 

The issue isn’t staff competence. It’s structural: 

• volume 
• urgency 
• fragmented context 
• pressure to resolve 
• and the absence of portable, cryptographically verifiable identity proof in the workflow 

This is also why recent Australian incidents have highlighted third-party customer service platforms and contact-centre systems as meaningful exposure points — not because service teams are “bad,” but because they sit directly in the line of trust. [6] 

4) The uncomfortable truth: incidents increasingly look “legitimate” in hindsight 

This is where executive teams struggle, because it doesn’t look like a traditional security failure. 

In many identity incidents: 

• the correct workflow was followed 
• approvals were made in good faith 
• the user “passed” what checks existed 
• the event logs look normal 
• nothing appears “broken” 

And yet the outcome is catastrophic. 

This happens when: 

1. identity is re-granted during recovery/exception handling 
2. the identity proof is insufficient (or non-existent) 
3. the attacker’s narrative fills the gap 
4. access is restored 
5. the system treats the attacker as legitimate thereafter 

This is why the phrase “assumed trust under pressure” resonates. It’s not a moral critique. It’s a design description. 

NIST’s Zero Trust framing is useful here, Zero Trust assumes no implicit trust should be granted based solely on network location or prior state, yet many organisations still implicitly trust identity during operational re-establishment moments because the workflow lacks strong identity proof. [7] 

5) Why “more controls” often makes this worse 

A predictable reaction is to add friction: 

• add more questions to recovery 
• require more approvals 
• lock down exceptions 
• force more MFA prompts 
• increase step-up authentication 

Sometimes this helps. 

Often, it drives the problem into the shadows: 

• staff bypass controls to keep operations moving 
• “temporary” exceptions become permanent 
• users shift to backchannels (“call my mobile”) 
• workarounds accumulate 
• real assurance decreases even as process steps increase 

This is not hypothetical. 

At scale, systems that add friction without adding proof tend to create the very conditions attackers exploit: fatigue, urgency, and inconsistent enforcement. 

The macro data supports this. When identity compromise is pervasive at the ecosystem level (Microsoft’s daily attack telemetry, DBIR breach patterns, Mandiant initial access vectors), raising friction alone does not change the attacker’s economics, it often changes the defender’s. [1][2][3] 

6) What leading organisations are doing differently 

The organisations moving ahead of this problem are not “buying another IAM tool.” 

They’re recognising the boundary between: 

• access control (policies, enforcement, authorisation) 
• and 
• identity proof (who is this person right now, at this decision moment?) 

Practically, that means: 

1. Treat identity re-establishment as a first-class risk surface 
2. Not an operational afterthought. 
3. Engineer recovery and exception handling as security workflows 
4. Not customer-service workflows. 
5. Design identity assurance that can be reused across moments 
6. Instead of re-asking humans to adjudicate from scratch every time. 
7. Minimise unnecessary data exposure 
8. Because recovery workflows can become an unintended data-collection and privacy risk surface, particularly in regulated environments. OAIC reporting reinforces that breach consequences and notification obligations continue to rise as malicious attacks persist. [5] 
9. Align to verifiable identity principles 

NIST’s Digital Identity Guidelines explicitly address identity proofing and lifecycle management concepts that become critical when identity must be re-established securely over time, not just once. [8] 

7) The executive question that changes the conversation 

A board will rarely ask: “Are our identity controls modern?” 

They will ask, after the wrong incident: “How did we let the wrong person in, when our controls were in place?” 

The executive pressure test is simple: If identity recovery, access changes, and exceptions doubled next year, would our confidence double with it? 

If the answer is unclear, the trust model does not scale. That is the risk. 

8) Where VO Verification fits (without replacing what you already have) 

VO Verification is designed for the exact gap described in this series: 

proving identity at the moment trust is re-granted, not just at onboarding. 

It complements existing environments including (but not limited to) IAM, MFA, Conditional Access, ticketing, service management — by adding a decision-grade verification layer that can be invoked: 

• during account recovery 
• for re-issuing MFA 
• for privilege elevation / exceptions 
• in contact-centre interactions 
• across high-risk operational moments 

The objective is not more friction. It is more proof with less data exposure. 

If this series reflects what you’re seeing, particularly the “legitimate in hindsight” pattern, the next conversation is straightforward: “Where is identity being re-established at scale in your organisation, and what evidence do you rely on at that moment?” If you want to pressure-test that with a peer lens, reach out. 

References (APA) 

1. Verizon. (2025). 2025 Data Breach Investigations Report (DBIR). Verizon Business.  
2. Microsoft. (2024). Microsoft Digital Defense Report 2024. Microsoft Security.  
3. Mandiant. (2025). M-Trends 2025: Executive Edition. Google Cloud.  
4. Australian Signals Directorate. (2025). Annual Cyber Threat Report 2024–25. Australian Cyber Security Centre.  
5. Office of the Australian Information Commissioner. (2025). Notifiable data breaches report: July to December 2024. OAIC.  
6. (Context example) The Guardian. (2025, July 2). Major Australian airline confirms cyber-attack exposed records of up to 6 million customers (contact-centre platform).  
7. Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture (NIST SP 800-207). National Institute of Standards and Technology.  
8. Grassi, P. A., Garcia, M. E., & Fenton, J. L. (2017). Digital Identity Guidelines (NIST SP 800-63-3). National Institute of Standards and Technology.