Nearly every enterprise we onboard is a Microsoft shop running Attack simulation training inside the Defender portal, and the first question is always whether they have to choose. The answer is no, and it is worth saying plainly before anything else.

Four things, up front.

• Nothing gets replaced. The licensed tool keeps doing what it is good at, and we do not run a competing product against the same techniques.
• The gaps get closed. Cloned voices, deepfake video participants, and live conversations are a different class of test, and they are where our engagements find the failures.
• You build your own content. Phishing lures, the pages behind them, and the awareness training, generated from your own policies or from the finding itself, in minutes.
• Flat platform fee, not per user. Priced by scope rather than seat count, which changes which tests you are willing to run.

Build Your Own Pages, Lures and Training

This is the part buyers are most surprised by, because the usual assumption is that simulation content and awareness content are things you are given rather than things you write.

Credit where it is due first. Attack simulation training has real authoring in it. You can build a custom payload with a rich text editor or straight in the HTML, set the sender and subject, drop in dynamic tags that pull a target's name or department, attach a file, choose the phishing link, and create login pages as part of building the simulation. That is a capable toolset and anyone telling you Microsoft makes you use canned lures has not opened the payload editor.

What takes the time is that all of it is hand-built, and that it stops at the message. Somebody writes the HTML. Somebody themes the login page. And then the training at the end of it is a pick from a catalog of more than seventy built-in modules, or a redirect to a custom URL that assumes a module written to your procedure already exists somewhere. In most organisations it does not, because writing one means sitting down with the wire approval procedure or the service desk verification standard and turning it into a lesson. So the catalog gets used instead.

The consequence is quiet and expensive. The catalog teaches a generic pretext. Your finding was about one verification step, in your procedure, using your ticketing system and your approval language. Those are not the same lesson, and the gap between them is a decent explanation for why completion rates keep climbing while the same control keeps failing.

On our platform the same source material produces the whole chain, and it produces it in minutes.

Minutes matters less as a speed claim than as a feasibility one. Keying a lure, a page and a lesson to the specific control that failed is only realistic when producing them is cheap. When it takes a quarter and an agency, everyone reaches for the catalog instead, and the program drifts back to teaching last year's pretext.

The generation is described on the OSES Behave page, and the video above walks through a help desk impersonation built end to end.

Start With What Attack Simulator Already Does Well

The payload editor is not the only thing Microsoft gets right, so here is the rest of it. This part gets skipped in most vendor writing, and skipping it is why those arguments do not land with anyone who actually administers the product.

Attack simulation training comes with Microsoft 365 E5 and Defender for Office 365 Plan 2, so the capability is already bought and paid for. It pulls who to test from your directory rather than from a spreadsheet someone maintains by hand. It schedules itself on a monthly or weekly rhythm without anyone rebuilding a campaign each time. It reports who clicked, who typed credentials, who approved a consent prompt, who reported it, and who finished the training. And it hands those results back out to whatever your security team already uses for reporting.

For running phishing simulations across a whole workforce, at volume, that is the right instrument. Buying a second product to repeat the same six simulations against the same people is money spent on a test you are already running. We say that to prospects before they ask.

Where the Simulations Stop, and What Runs Next

Attack simulation training runs six kinds of simulation, and Microsoft publishes the list, so the scope is a matter of record rather than a matter of opinion. A link to a convincing fake login page. A malicious attachment. A link hidden inside an attachment. A link to a malware file. A drive-by page. An app consent prompt. For message-borne phishing, those are the six that matter.

Every one of them finishes the same way. Somebody receives something, and then clicks, types, or approves. That is the capability, and run across a whole workforce on a monthly rhythm, it is a genuinely good one.

It also reaches beyond the inbox. Those simulations can land by email, by text message, or in Teams. Worth knowing, because plenty of buyers assume otherwise. But changing where a message arrives does not change what is being tested. There is still a message, still a recipient, and still a single moment where one person acts on it alone.

What none of those six simulations does is hold a conversation. None of them rings the service desk in your CFO's cloned voice and talks an analyst through resetting a password. None of them leaves a voicemail and then handles the employee who calls the number back. None of them joins a video meeting as a synthetic participant, camera on, and asks a finance approver to release a payment while colleagues watch and nobody wants to be the one who slows things down.

That is what we build. Breacher.ai runs deepfake phishing simulations as authorised engagements: cloned voice on the phone, synthetic participants on a video call, and a conversation that adapts when somebody pushes back. The point is never the quality of the fake. It is whether the verification step in front of the payment, the reset, or the access grant still happens once the person on the other end sounds exactly like someone they trust.

It is a different kind of test rather than a louder version of the same one. Note too that one of Microsoft's six, the app consent prompt, already tests a real privileged action outright. That is one less thing for anyone to cover, and a good illustration of why these two fit together instead of competing.

Closing the Gaps Without Replacing Anything

Four steps, and the first two need no product at all.

The per-person results stay useful the whole way through, as a way of deciding who gets which training next. Microsoft already flags repeat clickers and can aim the next simulation straight at them, which is exactly what that data is good for. It just answers a different question from whether the payment went out.

The simulations behind all of this are described on our help desk impersonation simulation, AI vishing simulation, and conference call phishing simulation pages.

Flat Platform Fee, Not Per User

Usually treated as a procurement detail, and it is not. The unit you are billed in quietly decides which tests you are willing to run.

The platform is priced by scope rather than by seat count. Scope reflects population band, the number of orchestrated channels, scenario complexity, and how much of the first cycle we run, and the figures are on the pricing page rather than quoted per conversation. What there is not is a per-head multiplier. Two consequences follow, and both are operational rather than financial.

Scoping stops being a budget negotiation. When testing meters per person, every scoping conversation becomes an argument about who to leave out, and the people left out are usually the ones a requester would have called anyway. Coverage is a denominator. Trimming the population to control cost shrinks the denominator and flatters the number.

Re-testing stops being rationed. Proving a control changed means re-testing the same control after remediation and measuring the delta. If each re-test meters per head, teams re-test less, and the third clause of the tagline quietly becomes aspirational. A flat fee makes it a scheduling decision.

Worth saying plainly, because the inverse claim would be easy to make and would not survive scrutiny: none of this is evidence that coverage rate is the right metric. It is evidence that nothing in the contract is working against it.

What We Do Not Claim

Every vendor in this market will tell you their control works. The useful question is what they say when it does not, so here is ours, stated before anyone has to ask.

• A verification requirement protects the paths you have written down. It says nothing about a privileged action nobody has listed yet. That is why the inventory step carries the weight, and why we treat it as the first deliverable rather than an afterthought.
• We do not claim a procedure never fails. A better fake does not defeat a callback rule directly, it just raises the pressure on the person following it, and what moves under that pressure is how often the rule gets waived. We measure that deliberately, because a number you can defend is worth more than a promise somebody can disprove.
• Microsoft's tool keeps its own published boundaries. Guest accounts and shared mailboxes sit outside its simulations, and on-premises mailboxes report less detail. Nothing we do changes that, so we count those people in the coverage picture rather than letting them fall quietly outside it.
• Your reviewer stays in the loop on generated training. A module written from your policy reflects your policy, which is exactly the point and also the reason someone who knows the process signs it off before it ships. Fast content is an advantage. Unreviewed content is not, and we build the review step into the flow rather than around it.
• Built for enterprise programs. This works best where a security team has the capacity to run its own scenarios and shape its own training, which is where the platform is aimed. Where you would rather we ran the cycle for you, managed delivery is available and plenty of clients start there.

Frequently Asked Questions