Blagging is social engineering that uses persuasive lies, flattery, or fabricated authority to obtain sensitive information or access. In identity security, it targets people rather than systems, tricking employees, help desks, or administrators into revealing credentials, resetting accounts, or approving actions that bypass IAM, PAM, and verification controls.
How blagging works
Blagging is a confidence-based social engineering tactic that succeeds by manipulating human judgement, not by exploiting software. The attacker may pose as an executive, supplier, auditor, colleague, or support contact, then use urgency, familiarity, or authority to make the target disclose information or perform an action they would normally challenge.
This matters because the “weak point” is often the approval process itself. A request that sounds routine can bypass normal scepticism when it arrives through a trusted channel, especially if the target is busy, pressured, or conditioned to help quickly.
Why blagging is dangerous
Blagging can expose credentials, MFA codes, reset links, internal procedures, customer data, or account access. It is dangerous in identity security because it turns trust into an attack surface, allowing an attacker to get past IAM, PAM, and verification controls without needing to break them technically.
Once an attacker convinces someone to act on their behalf, the compromise can look legitimate from the outside. That makes the technique useful for account takeover, fraud, internal reconnaissance, and later privilege escalation.
Common blagging scenarios
Typical scenarios include help desk impersonation, executive impersonation, vendor pretexting, payroll or finance manipulation, and requests to approve password resets or access changes. These are not limited to email, they can happen over phone, chat, SMS, or any channel where the attacker can sound credible.
The strongest versions of blagging use context that makes the request seem plausible, such as job titles, org charts, project names, incident language, or personal details harvested from public sources or previous breaches.
How organisations reduce the impact
Defence starts with process design, not just user training. Organisations should require step-up verification for resets, changes, approvals, and sensitive disclosures, and they should make it easy for staff to pause and verify out of band when a request feels unusual.
Social engineering controls are strongest when they are paired with least privilege, restricted help desk authority, strong identity proofing, and clear escalation paths for higher-risk actions. Published identity guidance such as NIST SP 800-63 Digital Identity Guidelines and control catalogues such as NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce verification, authentication, and access-control discipline.
Risk and Threat Considerations
Blagging is especially risky where staff can approve identity changes, reveal secrets, or override normal checks under pressure. It often succeeds by abusing trust, time pressure, and authority cues, which means the attacker does not need malware or technical exploitation to obtain access.
Failure mechanism: The attacker creates a believable context, then asks for a disclosure or action that seems low-risk in isolation but becomes dangerous when combined with privileged access or a reset path.
Impact: The result can be account takeover, unauthorised access, fraudulent transfers, exposure of sensitive information, and further movement through systems that trust the compromised identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Blagging often seeks credential disclosure or reset paths. |
| IA-2 — Identification and Authentication (Organizational Users) | The tactic targets human authentication decisions and approvals. | |
| AC-6 — Least Privilege | Limiting what helpers can do reduces the value of deception. | |
| Recommendation — Harden authenticator lifecycle checks before any reset or disclosure. Require strong user authentication before sensitive access changes. Restrict staff and help desk authority to the minimum needed. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Provides identity proofing and phishing-resistant authentication guidance relevant to impersonation abuse. |
| Recommendation — Use stronger identity proofing and phishing-resistant authenticators for sensitive workflows. | ||
| MITRE ATT&CK | T1566 — Phishing | Blagging is a person-focused social engineering technique in the same attack family. |
| Recommendation — Map suspected blagging to phishing-style lures in detection and awareness programs. | ||
Practitioner Guidance
Why practitioners should care: Blagging is a control bypass pattern, not just a user mistake. Security teams should treat any process that allows human approval of access, secrets, or resets as part of the attack surface, because the attacker’s goal is often to make the workflow itself do the work.
What to watch for: Requests that are urgent, unusually specific, emotionally loaded, or out of channel deserve extra scrutiny, especially when they involve password resets, MFA changes, shared secrets, or privileged actions. The safest response is a deliberate verification step that is independent of the original request path.