Is That Really ITECS Calling? A Safer Way to Verify Business Requests

An employee answers the phone. The caller says they are from ITECS, corporate headquarters, or another store. They know a manager’s name and sound comfortable discussing the business. There is an urgent problem, they explain, and fixing it requires opening a website, approving access, or sharing information.

The employee wants to help. That is precisely what an impersonator is counting on.

For business owners, operations leaders, and IT managers, the answer cannot be “tell everyone to be more suspicious.” Employees need a repeatable way to pause, verify, and get approval without having to investigate a caller themselves.

ITECS offers programmable hardware tokens that can be configured with corresponding one-time-password entries in its 1Password system. This gives designated client personnel—including retail managers without their own 1Password access—a physical device for an agreed caller-check procedure.

The important distinction: a matching code is an additional check, not permission to follow the caller’s instructions. Trusted callbacks and business approvals remain essential.

What attackers are actually asking employees to do

Voice phishing, often called vishing, turns a conversation into a route to systems, money, or information. Published investigations show several ways that happens.

“We’re IT support, and we can fix the problem”

Microsoft documented Storm-1811 attacks in which victims received a flood of unwanted email, followed by a caller impersonating IT support. The supposed helper persuaded employees to allow a Quick Assist connection. Attackers then used their access to introduce additional tools; Microsoft observed activity leading to Black Basta ransomware. The lesson is uncomfortable: an apparent support problem can be the setup for the fraudulent support call. Microsoft’s investigation.

“Visit this support page and sign in”

In the same investigation, Microsoft described malicious links leading to credential-stealing pages and Teams accounts presenting themselves as help-desk staff. A familiar application, professional display name, or plausible website does not make the request legitimate. The objective may be to steal a password or session rather than immediately install malware. Microsoft’s documented attack methods.

“Approve this application so we can resolve your ticket”

Google Threat Intelligence documented UNC6040 callers impersonating IT support and persuading employees to authorize attacker-controlled connected applications in Salesforce. That authorization enabled data theft and subsequent extortion. Google explicitly distinguished these attacks from exploitation of a Salesforce vulnerability: people were manipulated into granting access. A request to approve an integration can therefore be as consequential as a request for a password. Google’s UNC6040 investigation.

“You recognize my voice—please handle this urgently”

The FBI warns that criminals use AI-generated audio to impersonate public figures and personal contacts in financial fraud. Familiarity with a voice is no longer a sufficient check for a sensitive request. This does not mean every suspicious call uses AI; ordinary impersonation remains a problem too. FBI guidance on AI-enabled fraud.

These are documented external examples, not claims that ITECS or its clients experienced those specific incidents. For a smaller business, the operating lesson is the same: verify the request before helpfulness becomes access.

How a hardware token and 1Password fit together

A time-based one-time password, or TOTP, is a short-lived code calculated from a protected setup secret and the current time. A compatible programmable device and a software authenticator can show matching codes when provisioned with the same secret and compatible settings, with their clocks sufficiently aligned. They do not need to send each new code to one another. TOTP specification, RFC 6238.

1Password supports storing OTP information and displaying verification codes. Its documented capability is an authenticator feature; the telephone procedure described here is an ITECS use of that capability, not a separate caller-verification product from 1Password. 1Password’s OTP documentation.

For an enrolled business relationship, a designated client manager can hold the hardware device while authorized ITECS personnel use the corresponding protected entry. Clients already using 1Password may have a software-based option, subject to the agreed access and verification design.

This can be particularly useful where employees share workstations, personal phones are inappropriate, or not every shift worker has a password-manager account. The device belongs in a controlled process with a named custodian—not beside the telephone for anyone to use.

Hardware compatibility must be checked before enrollment. “Security key,” “hardware token,” and “programmable TOTP device” are not interchangeable descriptions of the same capability.

A practical sequence: pause, call back, compare, approve

The recommended procedure separates checking the caller from authorizing the work. It should be agreed and rehearsed before anyone receives an urgent request.

1. Pause the requested action. Do not open the supplied website, install software, approve a sign-in, disclose information, or change settings while establishing who is asking. Record the claimed name, organization, purpose, and ticket reference without sharing sensitive information.
2. Reconnect through a trusted route. Use the ITECS, headquarters, or location number already recorded in your approved directory. Do not rely on caller ID or a replacement number supplied during the call. The FTC warns against following links or phone numbers supplied in unexpected impersonation messages. FTC business-impersonation guidance.
3. Use the designated caller-check credential. Where the relationship is enrolled, the person claiming to represent ITECS or the other location supplies the current dedicated verification code. The receiving manager compares it privately against the correct device or entry. The recipient does not read their own displayed code back to “help the caller verify.”
4. Confirm the actual request independently. Establish that the ticket, purpose, website, and proposed access match the authorized work. A matching code does not establish that a link is safe or that the caller should control a computer.
5. Obtain the normal business approval. Payments, account recovery, sensitive exports, destructive changes, and remote access retain their usual approval requirements. Record the verification outcome and approver in the approved workflow—not the secret, QR code, or current token value.

If the code does not match, the device is unavailable, or the caller pressures someone to skip the process, stop the sensitive action and escalate through a known contact. A dead battery or urgent deadline is a reason to use a preapproved alternative, not to improvise a bypass.

Keep caller-check codes separate from login codes. This procedure must never use codes for Microsoft 365, banking, VPN access, a person’s 1Password account, or another sign-in. Never disclose those account codes, recovery codes, or approval prompts to a caller.

What this looks like at a retail location

Illustrative scenario—not a reported client incident:

A caller tells a store employee that headquarters needs an urgent “security update” on the checkout computer. The employee is asked to visit a website and download a utility.

The employee does not need to decide whether the website looks convincing. They pause the request and involve the designated manager. The manager contacts headquarters or ITECS through the established directory and checks whether the work is expected.

If it is legitimate and the caller-check procedure applies, the authorized caller provides the dedicated code for that relationship. The manager compares it privately with the assigned token. Only then does the business proceed through its normal approval process for the specific work.

If there is no confirmed work, no successful verification, or no appropriate approval, the download does not happen. The employee has followed a clear rule rather than challenged someone who merely sounded important.

The same principle applies between headquarters and branch offices. Before rollout, define who is checking whom and which credential applies; a shared location device does not identify the individual holding it.

What a matching code cannot prove

There is a reason to describe this as an additional check rather than an impersonation-proof system.

• Codes can be relayed. An attacker may obtain a current code from someone else and pass it on before it expires. NIST identifies OTP authentication as not phishing-resistant. NIST authenticator guidance.
• Short-lived does not automatically mean single-use. Comparing two displays does not record that a code has already been accepted. It provides no automatic replay blocking, attempt limits, or audit trail. RFC 6238 requires a verifier to reject a reused code after successful validation; a manual comparison alone does not provide that enforcement. RFC 6238, section 5.2.
• Shared access is not personal identity. Anyone holding the device or a copy of its setup secret can generate the same code. A site credential cannot, by itself, prove which employee is speaking.
• Possession is not permission. Even an authorized person can make an incorrect request or have another account compromised. The code does not approve a payment, prove a website harmless, or authorize a security change.

For those reasons, this approach supplements independently verified contact and approval procedures. It does not replace phishing-resistant account authentication, restricted administrative access, endpoint protection, or employee security training.

Set up the process before distributing devices

Treat enrollment as a small security project, not a hardware giveaway. We recommend documenting these decisions:

• Scope: Which client, location, and verification direction does each credential cover? Avoid one universal code shared across unrelated clients or sites. Separate credentials reduce the consequences of a loss, although they do not eliminate relay risk.
• Ownership: Who holds each device, who may access the corresponding vault entry, and who covers another shift? All holders of a shared secret can generate its codes; there is no cryptographically read-only holder.
• Provisioning: Use approved compatible devices and protect the setup secret. Do not distribute enrollment QR codes through ordinary email or general team chat.
• Exceptions: Define a trusted fallback for a lost device, unavailable manager, clock mismatch, or failed display. Sensitive work stays paused until approved verification is completed.
• Replacement: Revoke access and replace affected secrets when loss, exposure, or personnel changes warrant it. Removing someone’s vault access does not invalidate a secret they previously copied.
• Practice: Rehearse a genuine request, an impersonation attempt, and a mismatch. Record outcomes without retaining codes, and review whether employees know when to stop and whom to call.

These are recommended rollout controls, not a claim that every client already has the same procedure. ITECS and the business should agree the actual scope before relying on the devices.

Give employees permission to verify—even when the caller says “ITECS”

The most useful change is cultural as well as technical: checking a sensitive request is part of good service, not an obstacle to it.

A programmable token gives an authorized manager something concrete to check. A protected 1Password entry gives authorized support personnel the corresponding capability. A trusted callback and documented approval process give that comparison its proper context.

Together, those layers can make it harder for a convincing stranger to turn an unexpected call into an unapproved action. They cannot guarantee that every impersonation attempt will fail.

Talk with ITECS about a caller-verification process for your headquarters, offices, or retail locations. Start with who may request sensitive work, how employees independently reconnect, and what must be approved before anyone proceeds—not simply which device to buy.

Research note: This article uses primary-source threat research and authentication documentation, plus ITECS’s owner-provided description of its hardware-token offering. It was prepared with AI-assisted research and drafting. Before using this approach, confirm device compatibility and agree the enrollment, verification, approval, and recovery procedures with ITECS.