According to Cisco's Event Response, on 24 July 2025 (GMT+9) Cisco was made aware that a bad actor had targeted a Cisco representative through voice phishing, also called vishing. That call produced access to one instance of a third-party cloud CRM system Cisco uses. The actor exported a subset of basic profile information tied to Cisco.com user accounts: name, organization name, address, Cisco-assigned user ID, email address, phone number, and account-related metadata such as creation date. Cisco states the actor did not obtain organizational customers' confidential or proprietary information, passwords, or other sensitive information. Cisco identified no impact to products or services, and no other Cisco CRM instances were affected. Access to that instance was terminated and an investigation began. Public reporting does not name the CRM vendor, the threat actor, an exact affected-record count, or whether the handoff after the call was a password, a code, a reset, or a live session.
If you want the prevention angle on workforce CRM vishing and identity handover, read the related article on mfa2point0.com.
FAQ
What actually happened in the Cisco CRM vishing incident?
Cisco's CRM vishing incident started when a bad actor targeted a Cisco representative by phone. According to Cisco's Event Response, that voice phishing attack led to access and export from one third-party cloud CRM instance. The exported set was basic Cisco.com profile and contact-style fields, not passwords. Cisco was made aware on 24 July 2025, published the Event Response on 1 August 2025, and later assessed actor claims without finding evidence beyond the July picture.
Did attackers steal Cisco.com passwords or customer secrets?
No. Cisco states the actor did not obtain passwords or other sensitive information, and did not obtain organizational customers' confidential or proprietary information. What left that one CRM instance was a subset of basic profile data: names, organization names, addresses, Cisco-assigned user IDs, emails, phone numbers, and account metadata. Public reporting does not establish an exact headcount of affected records.
How did the vishing call turn into CRM access?
Public reporting does not establish the precise post-call path. Cisco confirms voice phishing of a representative and resulting access to one third-party CRM instance. It does not detail whether the representative shared a password, approved a factor, completed a recovery step, or handed over a usable session. CISA's guidance on social engineering and phishing treats live coaching of people into handing over access as a standard social-engineering class. The call was credential-phase social engineering of a workforce identity path into enterprise CRM, not a named AiTM kit story Cisco never described.
Were Cisco products, other CRM systems, or SSO federation in the blast radius?
Cisco says it identified no impact to products or services, and no other Cisco CRM instances were affected. Public reporting does not establish SSO or federation involvement in this path. The documented scope is one third-party cloud CRM instance plus a subset of basic profile fields, with access terminated once Cisco was aware.
Would stronger MFA have stopped the profile export itself?
Stopping the export after the actor already held CRM access is not an MFA job. MFA decisions sit on the earlier workforce access path the vishing call abused. Closing phishable live handover of credentials or recovery material shrinks that surface; a fix for that class of identity social engineering exists. Public reporting does not name Cisco's MFA layout or which factor failed. Once an authorized CRM session or role exists, containing export is revoke, access review, and CRM controls, not a second login prompt.
