Whatever your firm has approved is allowed to run and the rest is refused, ThreatLocker doing the deciding. Requests to elevate come to our team, so no closing waits on a policy.
Detection asks what a program has been doing. Allowlisting asks whether it may start.
Every defensive product on the market other than this one starts from permission. Anything may execute, and the job of the software is to notice quickly enough when something should not have. That model has served for thirty years and it fails in a predictable place: the first sample of anything, on the day it appears, is unknown to everyone.
Default deny inverts the question. A firm running an advisory practice, a title office, or a collections desk uses perhaps sixty applications, and it has used the same sixty for years. Everything else on the planet is, by definition, not needed. Permitting the sixty and refusing the rest removes an entire category of incident rather than shortening the response to it, and it does so without knowing anything about the threat.
The objection never changes, and it deserves an answer: what happens the day the business genuinely needs number sixty-one? Answering that is the part we operate, and it is why this arrives as a service and not as a licence key.
Learning, then a policy, then a person on the other end of the request.
ThreatLocker starts out learning rather than blocking. Across an observation window it writes down what your machines genuinely run, and that inventory, sharpened against behavioural data gathered from an enormous number of endpoints elsewhere, becomes the opening policy. Nothing gets refused while this is going on.
With the policy live, approved software starts and the rest does not. Updates are where friction usually arrives, so they are followed automatically and a routine version change does not present itself as an outage. Where a genuinely new need appears, the request arrives at the Fortify 24x7 desk and a person weighs it and answers. That is what separates allowlisting which survives an actual working office from allowlisting somebody quietly disables in week three.
- Approvals and elevation requests are handled by our team around the clock, not queued for your IT provider's next available slot.
- The permitted set is itself a software inventory, maintained as a side effect of running the control.
- Refusals are recorded, so an attempt to run something unapproved is visible rather than silent.
What this line asks of your firm in return.
Default deny is the strongest preventive control in this catalog and it is the one that asks the most of you. A firm that installs software casually, or that lets each adviser choose their own tooling, will feel it. The observation period has to be long enough to catch quarterly and annual processes, or the first tax season under enforcement produces a queue of approvals on the worst possible week.
We would rather say that plainly than sell the line and manage the disappointment afterwards. In practice the firms that get the most from it are the ones with a settled application estate and a low tolerance for surprise, which describes most of the readers of this page.
It also pairs, rather than competes, with the detection family. Allowlisting stops what tries to execute. It has nothing to say about a valid credential used by the wrong person through software that is entirely approved, and that is exactly the attack this industry sees most.
The element this line speaks to, and the one it does not
The rule requires a firm to implement and periodically review access controls, including technical controls that authenticate and permit access only to authorised users. Allowlisting speaks to that requirement from the execution end. Whatever a session may be entitled to open, it cannot launch a program the firm never approved, and the periodic review shows itself in the approval history instead of being asserted in a policy document.
The permitted set doubles as an inventory of the software in use, which contributes to the requirement to identify and manage the data, personnel, devices, systems, and facilities that enable the firm to achieve its objectives.
What this line does not do is authenticate anybody. The rule's multi-factor authentication requirement is satisfied inside your own identity systems, and no allowlisting product substitutes for it.
| Platform | ThreatLocker, run for your firm by Fortify 24x7 |
|---|---|
| Control model | Deny by default. What the firm approved may start; nothing else does |
| Policy origin | An observation window on your own machines, sharpened against behavioural data from an enormous endpoint population elsewhere |
| Update handling | Version changes followed automatically, so approved software moves forward without presenting as an outage |
| Elevation requests | Received, evaluated, and answered by the Fortify 24x7 desk, continuously |
| Operating systems | Windows and macOS endpoints and servers |
| Evidence produced | Permitted application inventory, approval history, and a record of refused execution attempts |
| Counted by | Each endpoint, monthly |
Where these lines stop
Nothing here authenticates anybody. It rules on what may run, never on who is signing in. Multi-factor authentication, unique user identification, and session management stay in your identity platform and remain your obligation.
It governs software, not documents. A user permitted to open a spreadsheet full of account numbers is still permitted to open it. Discovery and egress control live in the customer data family.
Software as a service is out of scope. Allowlisting acts on the endpoint. It has no view of what happens inside a browser tab connected to a platform you do not host.
Observation is genuine effort, not a formality. A firm with a seasonal application estate should let the window run across at least one full season, and should expect a burst of approval traffic once enforcement begins.
The words we are careful about
An FTC certification does not exist for any product, and no supplier is able to put a firm into compliance with the Safeguards Rule. That rule reaches financial institutions, and its duties settle on the Qualified Individual your own firm appoints. We sell technical services, plus the operating evidence those services leave behind, set out against the elements of 16 CFR Part 314 so that whoever signs the written program has something dated and specific to point to.
None of it promises a compliance verdict, a clean examination, or freedom from a security event, and none of it is legal advice. Which supervisor reaches your firm, what the written program has to contain as a result, and whether an event carries any duty to notify are all matters for your Qualified Individual and your lawyers.
Heads up: card statements show FORTIFY 24X7 - MoneyGuard Solutions is a Fortify 24x7 brand, and your subscription is billed by Fortify 24x7.