In short and in plain language
Some fraudsters call companies. They say they are the web host or the agency. They want a password or a code.
Such calls cause damage more often. Sometimes a machine makes the call. Sometimes the voice sounds real but was made by a computer.
The text shows simple rules. Hang up and call back yourself. Only use the number from your contract. Ask for a code word that only you both know.
Do not give a password or a code on the phone. Two people make big changes together. Write down each strange call.
Did something go wrong? Then change the passwords right away. Call your service provider on the known number.
The phone rings and the display reads “Hosting Support.” The caller knows the shop’s name, the shop system and the hosting provider, speaks calmly and sounds competent. There is a critical security hole, he says, the update has to go in today, and for that he briefly needs the admin account password or the code that is about to arrive by text message. This is how an attack on shop access can begin: not with a technical vulnerability, but with a conversation. The German digital association Bitkom measures that these routes are on the rise: in its latest survey, damage from automated robo calls rose from 3 to 14 percent of companies, and damage from deepfakes from 4 to 8 percent (Bitkom). This article shows which calls are typical for shop operators, why they work and which verification process protects access without slowing down the real service provider in an emergency: a callback on the number on file, an agreed code word, no credentials over the phone and two-person approval.
Key takeaways
- In the Bitkom survey of 1,003 companies with 10 or more employees, damage from automated robo calls rose from 3 to 14 percent, and damage from deepfakes from 4 to 8 percent (Bitkom).
- Attackers also call the real service provider: according to advisory AA23-320A, they posed as employees at help desks to have passwords reset and MFA transferred to a device they controlled (FBI/CISA).
- Calling back only on the number in the maintenance contract and using an agreed code word that works in both directions replace gut feeling during the call with a fixed procedure.
- Passwords, one-time codes, recovery codes, API keys and transfer codes are not given out over the phone. MFA resets, new admin accounts and plugins on request need a second person.
- A call log makes step-by-step probing visible. If data was handed over anyway: change access at once, check the back end and report a personal data breach without undue delay, where feasible within 72 hours, unless it is unlikely to result in a risk (Art. 33 GDPR).
How the fake service provider calls
The role changes, the pattern stays the same. The caller poses as someone the shop already works with and combines this with a reason that seems to allow no delay. The German Federal Office for Information Security (BSI) describes the core of such attacks as deception about the identity and intent of the perpetrator and cites the classic example of the supposed system administrator who calls because he allegedly needs the password to fix a system error (BSI). For online shops, the usual roles are easy to name:
- The hosting provider: reports a security incident, a server migration or a locked database and asks for the admin password, access to the hosting account or a confirmation code that “is about to arrive by text.”
- The agency or maintenance team: announces an urgent security update and asks you to install an extension from a link they send or to start a remote support tool.
- The payment provider: wants to “verify” the merchant account, asks for API keys or announces a change to the payout account.
- The domain registrar: warns that the domain is about to expire and asks for the transfer code that allows the domain to be moved to another provider.
- The vendor of an extension: announces a license check and allegedly needs back-end access for it.
None of these requests fits a service provider that does its job properly. A maintenance provider under contract installs security updates through its own access and an agreed process, as described on the security updates page. A call asking for a password is not part of that. The same applies to payment providers and registrars, which reach their customers through the customer account and written channels.
The reverse direction is revealing. Attackers do not only call the shop, they also call the service provider and pose there as the shop operator or one of its employees. The joint advisory AA23-320A by the FBI, CISA and other agencies describes attackers who posed as employees to get IT or help desk staff to provide sensitive information, reset the password and transfer multi-factor authentication (MFA) to a device they controlled (FBI/CISA). A verification process that only secures one direction leaves the other one open.
Robo calls shift the pattern further. An automated call can, for example, play a recording that announces a locked account and asks you to call back or press a key. Anyone who responds then talks to a person who takes over the actual questioning. This scheme is different from the takeover of customer accounts with stolen passwords covered in the article on account takeover: here, the target is the access of the people who run the shop.
What the Bitkom figures show
For its study on business protection, Bitkom surveyed 1,003 companies in Germany with 10 or more employees and annual revenue of at least 1 million euros by phone, between calendar weeks 16 and 23 of 2026 (Bitkom). Shops with very few employees are not covered by this population; the direction of the trend is still clear. Overall, 58 percent of the surveyed companies suffered damage from cyberattacks in the past twelve months (Bitkom).
For comparison: 18 percent of the surveyed companies suffered damage from attacks on passwords, and 11 percent from spoofing, where a false sender identity is faked (Bitkom). While classic types of attack cause damage less often according to Bitkom, AI-supported methods are visibly increasing from a low level: damage from automated robo calls jumped from 3 to 14 percent, and damage from deepfakes from 4 to 8 percent (Bitkom). The level is still low, but the increase within one year is clear.
Deepfakes or deceptively real calls and emails with a very personal touch make fraud easier and attacks harder to detect.
For defense, another figure is more telling. As a reason why an attack led to damage, 55 percent of the companies with damage cite inadequate identity and access management; only 8 percent cite a compromise via external service providers or suppliers (Bitkom). Applied to the fake service provider on the phone, this means: what matters is less the real partner than the question of who in your own company hands out, resets or unlocks access, and by what procedure.
The European view confirms the picture. In its Threat Landscape 2026, ENISA describes a threat group that posed as IT staff in vishing campaigns to steal single sign-on credentials and MFA codes, and notes that cybercriminals increasingly targeted third-party providers such as digital services (ENISA). Vishing stands for voice phishing, meaning phishing by phone call or voice message.
Why the call works
According to the BSI, social engineering exploits human traits such as helpfulness, trust, fear or respect for authority to manipulate people (BSI). On the phone, three amplifiers come into play that a written request does not have.
Time pressure leaves no room for questions
A call demands an answer during the conversation. Anyone who wants to check or ask first has to insist on it actively while the caller points to the open security hole, the looming outage or the blocked payout. The MITRE ATT&CK knowledge base describes this technique as impersonation: attackers pose as a trusted person or organization, such as an executive, a colleague or a third-party vendor, to persuade their target to take an action (MITRE ATT&CK).
What the caller knows is public
The shop name, the legal notice, the shop system in use, the payment methods and often the hosting provider can be seen from the outside. Add to that names from career pages and professional networks. The BSI points out that social networks give attackers an easy way to collect a wide range of background information about a company’s employees in advance (BSI). Advisory AA23-320A also describes a multi-stage approach: first, the attackers find out what steps a password reset at the help desk requires, then they gather the matching details about the target person in further calls, and finally they ask specifically for the reset (FBI/CISA). Judging a caller by how well informed he is therefore tests the wrong thing.
Numbers and voices prove little
A displayed phone number shows which number was transmitted, not who is on the line. German lawmakers have responded to misuse: if a call showing a German number is handed over from a foreign network, the caller ID display must be suppressed (Section 120 (4) TKG, the German Telecommunications Act). That does not replace an identity check, especially since a caller can also call with a withheld number and claim a new direct line. The situation is similar with voices. The FBI warns that a genuine call from a known person and an AI-generated voice clone can sound nearly identical, and advises verifying new contact details through a previously confirmed channel (FBI).
Four rules for every call
The following rules do not rely on spotting the fraud but on the procedure. They work even when the caller is convincing because they require no judgment during the call. Anyone who applies them does not have to decide whether a voice sounds genuine.
Call back only on the number on file
If a supposed service provider asks for an action, the call ends with a friendly sentence: “I will call you back on the number in our contract.” The callback uses the number from the contact list, not the number on the display, in an email signature or from a search engine. MITRE ATT&CK lists confirming incoming requests through an independent channel, such as a phone call or in person, as a mitigation against impersonation (MITRE ATT&CK); the FBI recommends identifying the person’s number independently and calling back to verify (FBI). A real service provider knows this rule and waits for the callback.
An agreed code word in both directions
A code word is a word or phrase that only the shop and the service provider know and that is given at the start of a sensitive conversation. It does not open any access; it only shows that the right party is on the other end. The FBI advises private individuals to agree on a secret word or phrase within the family to verify identities (FBI); in business, the same can be set out in the maintenance contract. Three points make it robust: the code word works in both directions, including when the shop calls the service provider. It is not kept in the inbox but in a password manager or a sealed annex to the contract. And it is changed as soon as it has been used in a doubtful conversation or someone who knows it leaves the company.
No credentials over the phone
Passwords, one-time codes from text messages or apps, recovery codes, API keys and domain transfer codes are not given out over the phone, not even in part and not even after a successful callback. The BSI advises against sharing passwords, credentials or account information by phone or email (BSI). A service provider under contract does not need them anyway: it works with its own personal accounts that the shop assigns and can revoke. How to do this without forgotten accounts is described in the article on offboarding and access inventory.
Two-person approval for anything that changes access
Some requests are too consequential for a single decision, even after a callback and a code word: resetting MFA, a new admin account, installing an extension from an outside source, changed payout or bank details, changes to DNS and the domain. For these cases, the four-eyes principle applies with a ticket: one person takes the request, a second one checks and approves. After a series of attacks on the retail sector, the UK’s NCSC strongly encouraged organizations to review help desk password reset processes, including how the help desk authenticates staff before resetting passwords, especially those with escalated privileges (NCSC). The login technology itself, from MFA methods to roles, is covered in the article Shop admin access hardening.
- Note the request, the name given and the displayed number, confirm nothing
- Call back on the number from the contact list
- Ask for the code word before discussing any details
- Do not give out passwords, codes or keys, not even in part
- Change access only via a ticket and with a second person
- Record the call and its outcome in the call log
What belongs in the maintenance contract
A verification process only holds if both sides know it and feel bound by it. That is why it does not belong in a circular email but in the contract or in an annex that is updated with every change. Which points a maintenance contract should cover in general is shown in the article Maintenance contract: what to include. For calls, the following provisions are added.
| Provision | What is recorded | Purpose |
|---|---|---|
| Contact list | Names, roles and callback numbers of both sides with the list’s date | Callbacks only go to known numbers |
| Code word | Where it is kept, change after suspicion or staff changes | Both sides verify each other |
| Channels | Requests by ticket or after a callback, no credentials by phone or email | A caller outside these channels stands out |
| Approvals | Which changes need two people: MFA, admin accounts, extensions, payment details, DNS | No single person can approve anything consequential alone |
| Emergency route | Emergency number and code word outside business hours as well | Urgency is a typical pretext |
| Reporting route | Who informs whom in case of suspicion, including incidents at the service provider | Suspected cases reach both sides |
| Log | Date, request, number and result of the callback | Repeated calls become visible as a pattern |
The reporting route also has a legal side. If the service provider processes personal data on behalf of the shop, it notifies the controller without undue delay after becoming aware of a breach of that data (Art. 33 (2) GDPR). If a fake caller manages to take over an account at the service provider, the information thus reaches the shop through a defined channel.
A clear division of responsibilities also helps, as described in the article Hosting provider or maintenance. It makes fraud easier to spot: if “the hosting provider” asks about the shop back end although it only looks after the server, that is a clear reason for a callback. The SLA maintenance contract can record the verification process together with response times and a dedicated contact.
The call log makes patterns visible
A single odd call seems harmless. Several calls that ask in turn about the steps of a password reset, the name of the person in charge and finally a code add up to a picture. Advisory AA23-320A describes exactly this step-by-step approach (FBI/CISA). It only becomes visible if the conversations come together in one place. A log entry includes:
- Time: date and time as well as the person who took the call.
- Caller: displayed number, name given and supposed company.
- Request: in one sentence, plus the data or actions requested.
- Outcome: callback made or not, code word right or wrong, request confirmed or rejected.
- Escalation: who was informed, in-house and at the service provider.
The log does not need its own software; a shared form is enough. It should, however, be kept in a place the service provider may read in suspected cases, and it needs a deletion period because it contains names and phone numbers. It also pays to look at the back end: new admin accounts, newly created integrations and unexpected logins shortly after a suspicious call are a warning sign. Shopware maintenance includes regular reviews of user accounts, and monitoring raises an alert on unexpected changes to DNS records.
If credentials were handed over anyway
Even trained teams occasionally give something away, especially when the call was well prepared. What matters then is the order of the steps, not the question of blame.
End the call
Confirm nothing further, give out no more codes and do not confront the caller. Write down what happened right away.
Lock and change access
Change affected passwords, end all active sessions, set up multi-factor sign-in again and revoke any API keys that were mentioned.
Check the back end
Compare new admin accounts, integrations, installed extensions, changed payment and payout details and DNS records with the last known state.
Inform the service provider
Call the real service provider on the number on file. It checks its side and can trace logins in its own logs.
Secure the evidence
Save server and application logs before they rotate and mark the period starting with the call.
Assess data protection
Check whether personal data may be affected and assess the reporting obligation.
Confirm nothing further, give out no more codes and do not confront the caller. Write down what happened right away.
Change affected passwords, end all active sessions, set up multi-factor sign-in again and revoke any API keys that were mentioned.
Compare new admin accounts, integrations, installed extensions, changed payment and payout details and DNS records with the last known state.
Call the real service provider on the number on file. It checks its side and can trace logins in its own logs.
Save server and application logs before they rotate and mark the period starting with the call.
Check whether personal data may be affected and assess the reporting obligation.
A deadline applies to the last step: in the case of a personal data breach, the controller notifies the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons (Art. 33 (1) GDPR). The article API keys and secrets rotation helps with rotating keys, and the emergency plan for hacked websites describes the full process after a break-in. If you need help with this, emergency support is available even without an existing contract.
Anchoring the process in the team
Rules that only exist in the contract do little on the phone. They take effect when everyone who answers calls for the shop knows them without looking them up: temporary staff, customer service and vacation cover included. Six building blocks help with this.
Card by the phone
The four rules and the callback numbers on one page, printed next to the phone and stored in the ticket system.
Short briefing
For new employees on their first working day, for everyone else whenever the contact list or the code word changes.
Permission to say no
Management makes clear that a callback is welcome, even when management itself is supposedly calling.
Announced exercise
A test call by the service provider, agreed with management and without exposing individual people.
Regular review
Check the contact list, code word and approval rules twice a year and note the status in the contract annex.
Blame-free reporting
Anyone who gave something away reports it at once. Early reporting limits the damage, accusations delay it.
A procedure also protects the people who answer the call. Anyone who calls back as a rule does not have to stand up to a friendly, well-informed caller during the conversation but can simply refer to the agreed process. The effort for the shop remains manageable: a contact list, a code word, an approval rule and a form. How access is managed and documented centrally as part of ongoing shop support is shown in the services overview.
Sources
Related Articles
What Does Shop Maintenance Cost? The Key Cost Drivers
What shop maintenance costs depends on extensions, custom code, integrations and response time. How to plan a 2027 maintenance budget you can justify.
Penetration Test for Your Shop: When It Is Really Worth It
Scan or penetration test? When a test pays off for an online shop, how to set scope and test environment, and how findings move through to the retest.
Fake Customer Accounts: Stop Bot Sign-ups in Your Shop
Bots create fake customer accounts in bulk. Learn how to spot bot sign-ups in your shop and stop them with confirmation emails, rate limits and a honeypot.