Social engineering is the only attack category that targets the one component nobody can patch. Every defence against it has therefore been a defence of the person: train them, warn them, test them, and hope that on the day the call comes they notice. Against a superintelligent impersonator who looks and sounds exactly like the CFO, that hope is the control, and it is not a control.
There is a different place to stand. However the attack is delivered, by email, by voice, by video, by a patient relationship over months, it has to end in an action on the network: a payment is sent, a payee is changed, a password is typed, a code is read out, an access grant is approved, a file is exported, a setting is changed. The person is the delivery mechanism. The action is the objective. And the action happens at a place the attacker never reaches, which is the wire.
Why a hardware layer, specifically
A control that lives in the person's inbox, browser or phone can be bypassed by whatever channel the attacker uses next. A control that lives on an endpoint can be turned off, uninstalled or simply absent from the device that was never enrolled. A control that lives in-line at the chokepoint of the intranet, between the edge and everything behind it, is on the path of every consequential action whether the person, the device or the attacker likes it or not.
Monolith is that layer. It is a purpose-built appliance with its own attested compute, sitting in-line, with no dependency on the endpoint being honest and no dependency on the person being right. From that position, social engineering stops being a judgement problem and becomes an enforcement problem.
The control set
What follows is the feature set that position makes enforceable. Each one is designed on the same principle: the attacker controls the conversation, so take the decision out of the conversation.
Channel-origin attestation. Any request that claims to be internal must come from an attested endpoint on the intranet: measured boot, verified host image, attested runtime, bound to a named identity. A call, a message or a video session claiming to be the finance director that does not originate from the finance director's attested device is not internal, and the recipient's client says so, in real time, before they act. The deepfake can look right. It cannot attest.
Consequential-action hold. Payments above a threshold, new or changed payees, bank-detail changes, privilege grants, MFA resets, mailbox-rule changes, large exports and administrative changes are held at the chokepoint for confirmation on a second channel that the request did not come through. The attacker who owns the email thread does not own the attested device that has to confirm it. The hold is short, the confirmation is one tap, and the record is written whichever way it goes.
Approval bound to the action. A confirmation covers one specific action, with its amount, its destination and its time. A changed amount, a changed account or a replayed request needs confirmation again. "You already approved this" stops being an argument the attacker can make.
Impersonation infrastructure blocked at the wire. Lookalike domains, homoglyphs, newly registered domains that resemble your names or your vendors' names, certificates freshly issued for them and sending domains that fail authentication are identified continuously and blocked at egress before a person can reach them. A domain registered three days ago that is one character off your payroll provider does not get a connection from inside the estate, no matter how convincing the email that pointed to it.
Just-in-time interrupt. At the moment of a risky action, not before and not in a training module six months earlier, the chokepoint interposes: this domain was registered on Tuesday; this invoice came from a sending domain that is not the vendor's; this payee was changed an hour ago by a request that was never confirmed; the person you are on a call with is not on an attested device. The interrupt carries the evidence, and it carries a verify button that routes through Monolith rather than through anything the attacker supplied.
Credential flow control. Passwords, tokens and one-time codes are allowed to travel only to origins on the identity provider allow-list. A credential-shaped submission to a page that is not your single sign-on is held and the person is told why. OAuth consent to an application nobody has approved, the consent-phishing route that bypasses passwords entirely, is blocked at the chokepoint until the application is reviewed.
MFA-fatigue correlation. A burst of push notifications to one identity, an approval that follows, and a session that then originates from a device or location that identity has never used, is a pattern, not three unrelated events. Monolith correlates them at the wire, treats the approval as suspect, and holds the session pending verification on the attested device.
Help-desk and reset protection. The reset request that walked an attacker into a casino operator's network is the canonical social-engineering move, and it works because the help desk is asked to make an identity decision over the phone. Monolith gates resets, re-enrolments and recovery flows on the presence of the identity's attested device, or on confirmation by a named approver through a channel the requester did not choose. A help-desk agent cannot be talked into bypassing a control they do not operate.
Payee and vendor ledger. Vendor bank details are a protected record. A change goes through dual verification on attested devices, with the vendor confirmed through contact details held on file rather than supplied in the change request. Payment traffic to a payee whose details changed within the holding period without that verification is stopped at the chokepoint, regardless of who approved the invoice.
Verified presence on calls. For a voice or video session that will carry an instruction, Monolith can issue a one-time presence token to the claimed participant's attested device. If the person on the screen cannot produce it, the recipient knows before the request is made. Where the question is whether the human on the screen is real and unassisted at all, ScreenComply answers it, and the two together cover the deepfake on both axes: is this device theirs, and is this a person.
Network-level isolation when it lands. Social engineering sometimes succeeds. A credential used from a new device, a session that begins exporting, an identity reaching systems outside its purpose, an agent that was just installed on a workstation by a "support technician": Monolith isolates the host, the identity, the agent or the segment at the wire in seconds, revokes the credentials, blocks egress and freezes the session, with the whole chain evidenced. The person made a mistake. The mistake does not become the breach.
Exercised against the twin, continuously. Current social-engineering campaigns from sector bulletins, including the voice and video variants, are decomposed into their action chains and run against your digital twin. If the twin would have let the payee change through, or the reset through, or the connection to the lookalike through, that is the finding, and the control is written and verified before the real call comes.
What this does for the person
It stops asking them to be the control. They can take the call, read the email, believe the video. When they go to act, the action is held, verified, blocked or allowed by a layer that was never in the conversation and cannot be persuaded. The training poster becomes a courtesy rather than the last line of defence, and the person who was fooled is no longer the person who is blamed.
What this does for the CISO
Social engineering becomes a measured, exercised, evidenced control domain like any other. The command view shows actions held, actions verified, impersonation infrastructure blocked, resets gated and isolations taken, with the evidence record behind each one. When the board asks what would have happened if the CFO call had come to your finance team, the answer is a twin result rather than an opinion about how alert the team is.
Frequently asked questions
Can a network appliance really stop social engineering?
Not by reading the conversation; by governing the action. Every social-engineering attack has to end in an action on the network, and an in-line appliance at the chokepoint is on the path of that action. It can require attestation, hold the action for out-of-band confirmation, block the infrastructure the attack depends on and isolate a session that has already been compromised. That is enforcement the victim cannot be talked out of.
How is this different from email security and awareness training?
Email security filters one delivery channel; awareness training asks the person to notice. Both can be bypassed by a convincing enough impersonator on a different channel. The hardware layer does not depend on the channel or the person: it acts at the point where the attack has to touch the network to succeed.
What is a consequential-action hold?
A short pause enforced at the chokepoint on high-impact actions such as payments, payee changes, privilege grants, MFA resets and large exports, pending confirmation on an attested device through a channel the original request did not use. The attacker who controls the conversation does not control the confirmation.
How does Monolith handle deepfake voice and video calls?
By attesting the origin rather than judging the face. Internal requests must come from attested devices bound to named identities, a one-time presence token can be demanded of the claimed participant's device, and ScreenComply verifies that the human on the screen is real and unassisted. The call can look perfect and still fail every one of those checks.
What happens when social engineering succeeds anyway?
Monolith isolates at the network layer: the host, identity, agent or segment is cut off at the wire in seconds, credentials are revoked, egress is blocked and the session is frozen, with the full chain of evidence recorded. The compromise is contained before it becomes a breach, and the record shows exactly what happened.