A vishing simulation works because the secure email gateway you sold the client has no visibility into a phone call. Neither does it see a text message. The controls stop at the mail flow, and the attacker walked around them, which is why help desks keep resetting MFA for people who never asked. MSP Pentesting runs voice and SMS social engineering under your brand, channel-only, with the authorization paperwork written before anyone picks up a phone.
That last part is not a formality.
Voice and SMS testing carries real legal exposure that email phishing simply doesn't, and an MSP who runs one carelessly can hand a client a problem instead of a report. Get the constraints right first, then run the test.
What these channels actually are
Vishing is voice phishing. Somebody calls a target and talks them into an action: reading back a code, approving a push, resetting a credential, paying an invoice.
Smishing is the same idea over SMS or RCS. A short message with urgency and a link, or a message that starts a conversation and moves to a call.
Pretexting is the invented context that makes either one plausible. It's the actual technique. The channel is just delivery.
Attackers moved here for a boring reason. Email defenses got good. A voice call hasn't got a header to inspect, an SPF record to check, or an attachment you can detonate in a sandbox. Your technical stack contributes nothing, and the only control left is a human under time pressure.
Which is the whole argument for testing it.
The legal constraints, honestly
Most articles on this topic skip this section or wave at it. Don't. Four separate bodies of law touch a voice or SMS simulation in the United States, and none of them care that you meant well. They aren't obscure, either.
None of what follows is legal advice. It's the list of things to put in front of counsel before you sell the engagement.
Recording consent varies by state
Federal law sets a one-party consent baseline under 18 U.S.C. 2511, so a participant can generally record their own call. About a dozen states go further and require all-party consent. California, Delaware, Florida, Illinois, Maryland, Massachusetts, Montana, Nevada, New Hampshire, Pennsylvania and Washington get cited most often, and a few others get argued about at the edges.
Interstate calls are the trap. When the caller's in a one-party state and the target's in an all-party state, assume the stricter rule applies. Courts haven't been uniformly kind about this, and the edge cases aren't settled.
The practical answer for a simulation: either get documented consent covering everyone who might be recorded, or don't record. Contemporaneous tester notes plus call metadata are usually enough evidence for the report. Recording's nice for a debrief video. It isn't worth a wiretap claim.
Caller ID spoofing is a statute, not a technique
The Truth in Caller ID Act, at 47 U.S.C. 227(e), makes it unlawful to knowingly transmit misleading or inaccurate caller identification information with the intent to defraud, cause harm, or wrongfully obtain anything of value.
The statute says $10,000 per violation. That's the 2010 number. What the FCC actually assesses is the inflation-adjusted figure in 47 CFR 1.80, currently $14,432 per violation, three times that for each day of a continuing violation, and up to $1,443,275 for a single act.
Authorized testing isn't fraud, and intent is a real element of the offense. But there's no clean statutory carve-out that says "unless you had a signed scope document," and the risk isn't only regulatory. Spoof a real vendor's number and you've handed that vendor a claim against your client.
The rule we run: use a number you control. Never display a real third party's caller ID. If the pretext needs a plausible number, buy one and register it. The test still works, because targets don't verify numbers. They respond to urgency.
TCPA applies to your SMS campaign
The Telephone Consumer Protection Act restricts calls and texts to wireless numbers. Two pieces matter for a smishing simulation.
First, autodialers. After the Supreme Court's 2021 decision in Facebook v. Duguid, equipment only counts as an automatic telephone dialing system if it stores or produces numbers using a random or sequential number generator. A platform texting a supplied employee list probably isn't an ATDS. Probably.
Second, and independent of that, the prohibition on prerecorded and artificial voice calls to wireless numbers doesn't depend on the ATDS question at all. In 2024 the FCC confirmed that AI-generated voices count as artificial for this purpose, which closes the door on anyone thinking about cloning an executive's voice for a simulation. Use live callers.
Statutory damages run $500 per violation and treble for willful conduct. A few hundred employees is not a rounding error.
Whose phone is it
This is the question that decides most smishing scopes. Texting a company-issued number a company controls is a very different posture from texting an employee's personal cell.
An employer's consent isn't the employee's consent. If the numbers came off an HR emergency contact list, they weren't collected for this and you shouldn't use them. Scope to corporate numbers, or run a genuine opt-in inside the awareness program and keep the records.
Several states also require employers to notify staff about electronic monitoring. Check the client's employee handbook and their state before you assume the acceptable use policy covers it.
The carriers have their own rules
Below the law sits the messaging ecosystem. US application-to-person traffic runs through 10DLC registration and carrier content policies, and a message engineered to look like a credential-harvesting attack is exactly what those filters exist to stop.
Your simulated messages will get filtered. Rotating numbers or obfuscating links to beat that filtering isn't clever, it's a policy violation and a fast way to get your sending numbers blocked for good. Register the campaign properly, accept some delivery loss, and report on what actually landed.
Scoping an engagement that won't blow up
The authorization document does more work than the test plan. It's what you point at when an employee complains, when a client executive gets surprised, or when somebody calls the police.

Three things belong in every one of these and get left out constantly.
A named authorizing officer. One human at the client, senior enough to authorize, who can be reached during the test window. Not "IT."
A stop condition. A word or a phrase that ends the engagement immediately, plus who can invoke it. Targets escalating to law enforcement is the classic trigger.
An out-of-scope pretext list. Written down, agreed in advance. Layoffs, bonuses, bereavement, medical information, HR investigations, and anything impersonating law enforcement or a regulator. Impersonating a federal officer is a crime under 18 U.S.C. 912, and no scope document fixes that.
Pretexts that trade on genuine fear do work, which is exactly the problem. Write the off-limits list into the authorization. No bereavement, no layoffs, no payroll errors, no medical. Get the client to sign it. That list is what gets you invited back.
How a voice test should actually run

Brief the help desk lead, not the whole team. You need one person who knows the engagement is live so that a genuine incident gets separated from your test, and you need the rest of the team behaving normally.
Capture the outcome, never the secret. If a target reads back a one-time code, log that they read back a code and when. Don't store the value. Don't stand up a credential capture page and keep what people typed. You're documenting a behavior, not building a breach.
Debrief within a day. The coaching value of a failed call collapses fast, and delayed feedback reads as a gotcha.
What to measure
Click rate is the wrong headline metric for these channels, and for phone calls it barely means anything.
Measure the report rate. How many people hung up and told somebody. That's the behavior that stops a real attack, and it's the only number that reliably improves with training.
Then measure two process things that have nothing to do with the employee.
Help desk verification. Did the desk verify identity before resetting anything, and how? If the answer is "they knew the employee ID number," your client has a control problem, not a people problem.
Time to escalate. From first suspicious contact to somebody in security knowing. That number tells you more about the client's resilience than any percentage of failures.
| Channel | What the tech stack sees | Main constraint to clear |
|---|---|---|
| Headers, SPF and DKIM, links, attachments | Allow-listing the sending infrastructure | |
| Voice | Nothing usable, no artifact to inspect | Recording consent and caller ID law |
| SMS | Carrier filtering only, not your controls | TCPA consent and 10DLC registration |
Where this fits in the service line
Voice and SMS testing is an add-on, not a standalone product. Sold alone it's a novelty. Sold as the escalation path out of an existing awareness program, it's the engagement that proves the program covers more than one channel.
The sequence that works: run the email program monthly, establish a baseline report rate, then introduce voice against a small, high-value group like finance and the help desk. If you're building that broader offer, the mechanics of running a phishing simulation program rather than just a tool is the piece to get right before you add channels.
Because you administer the client's identity stack, you can't credibly test the help desk process you wrote. A white-labeled social engineering test under your brand gives you the finding without the conflict, and keeps your team in the remediation seat.
Questions MSPs ask about vishing and smishing tests
Do we need written consent from every employee?
For calls to corporate lines during work hours, the employer's authorization plus policy notice usually covers it. For texts to personal phones and for any recording, that changes, and it depends on which states are involved. That's the counsel conversation, and it's a short one.
Can we use AI voice cloning to make it realistic?
No. The FCC treats AI-generated voices as artificial voices under the TCPA, and cloning a named executive raises problems well beyond that statute. Live callers with a good pretext outperform synthetic audio anyway.
How often should a client run one?
Once or twice a year for voice, against a targeted group. It's labor-intensive and it burns pretexts you can't reuse. Email simulations run monthly because they're cheap and automated. These aren't either.
What if an employee reports it to the police?
Stop the engagement, notify the authorizing officer immediately, and have the authorization letter ready. This is exactly why one named person at the client has to be reachable for the whole window.
Will an auditor accept a voice test as evidence?
On its own, rarely. Most frameworks ask for awareness training and periodic testing without naming a channel, so a voice test strengthens the evidence file rather than replacing the program. Put it in the appendix of the awareness report, not in place of one.
Put the phone channel on the test plan
Pick one client with a mature email awareness program and a help desk that resets MFA. Write the authorization document first. Scope voice only, corporate numbers only, no recording, ten targets in finance and support.
Run it once and watch what the help desk does.
That result sells the rest. Under your brand, with the paperwork written before anyone picks up a phone. Get a pentest quote and tell us which states the client's staff sit in, because the consent rules follow the phones.


.png)
.avif)
.png)
.png)
.png)

