Intego False Positives: Trust, Restore and Rescan

False-positive decision matrix: act on the evidence you actually have

The correct first action is almost always “leave quarantined and investigate.” Don't click Trust or Restore first: deleting may destroy a required clean document or application, while trusting may restore a threat and hide it from every later scan. Quarantine keeps both possibilities open while preventing ordinary access and preserves a reversible decision point.

If the file ran before quarantine, the job expands. A clean result for that one path can't rule out persistence, a dropped helper, login item, browser extension or synced copy. Use the immediate workflow here, then the broader scan and history process in our VirusBarrier scans and quarantine guide.

A false positive is an incorrect verdict, not an inconvenient alert

A false positive occurs when the detector classifies a benign item as malicious or unwanted. “I need this file,” “the developer says it is safe,” “another scanner was quiet” and “the name is Microsoft” don't establish that. Legitimate software can be compromised, repackaged, altered after signing or bundled with unwanted behavior.

The opposite mistake matters too: an alert isn't courtroom proof that every byte is malicious. Heuristics deliberately flag patterns and behavior before a perfect name exists; definitions can misclassify a clean component. The right response preserves the item and context long enough to distinguish those cases.

Historical Intego community incidents make the point without deciding today's file. In 2023, users reported Office/AdLoad and XProtect Remediator detections that later comments said Intego corrected through definitions. Some people deleted or trusted immediately. We use those old reports only as evidence that definition errors can happen—not as a reason to dismiss a current detection with the same-looking name.

ONE, X9 and the free Scanner use different words for a risky restore

ONE also exposes Ignore. Its current Antivirus guide says Ignore removes the item from the quarantine list without changing the file. That's neither repair nor a clean verdict. It can make the dashboard quieter while leaving the underlying question unresolved.

Never translate “restore” as “undo safely.” In the free Scanner, holding Option changes the action and creates a trusted exclusion. In X9/ONE, Trust declares the item safe enough not to scan. The next meaningful clean result requires removing that bypass first.

The first 15 minutes: freeze the state before changing it

Leave the file in quarantine and avoid opening the original application, installer or document. Capture the Intego generation, application version, definition timestamp, detection name, original path, scan type, detection time and exact buttons shown. A screenshot is useful, but also copy the text because support can't search pixels.

Update Intego and its definitions without restoring the item. Then rescan the quarantined item or the original controlled scope if the product allows it. A definition correction can remove a bad verdict quickly, while an unchanged or more specific name gives you new evidence. Record both timestamps so “after update” is provable.

If the detection occurred during a real-time event, note what created the file: browser, mail client, sync service, installer, package manager or another application. Disconnecting the network is reasonable when the item executed or is recreating itself, but don't erase logs, clean caches or uninstall everything before preserving the source chain.

Build an evidence packet that support and the developer can use

A useful packet separates identifiers from private content. It includes product generation/build, macOS version, definitions, detection label, scan type, original path category, file size, acquisition URL or App Store receipt, expected publisher/version, and a SHA-256 hash. Redact usernames, customer names, project paths, serials and document content before a screenshot leaves the Mac.

Hashes are especially useful when the file can't be shared. Generate one locally with shasum -a 256 "/exact/path/to/file"; quotation marks matter when the path contains spaces. A hash is a fingerprint, not an analysis. Compare it only with an independently published value or known submission—never with a number pasted by the same untrusted download page.

Verify the source chain before trusting the file

Start at acquisition. Was the item installed from the Mac App Store, the developer's authenticated account, an official update channel, a search ad, a mirror, a crack or an unsolicited message? The same filename can describe an authentic application, a repackaged installer or an unrelated payload. Return to the official source and compare version, package size and published release notes.

For a document or macro detection, the publisher is the sender or business process rather than a Developer ID. Confirm the message through a separate channel, inspect whether the document unexpectedly asks for macros, credentials or security overrides, and keep it isolated. A trusted colleague's mailbox can be compromised; sender familiarity is context, not proof.

If an application came through an official updater but the hash changed unexpectedly, ask the developer whether that exact build is current. Developers should publish immutable hashes or signed release metadata where practical. Readers shouldn't weaken Gatekeeper or add broad security exclusions merely because a support script says the unsigned build is “normal.”

Use Mac signing and notarization as strong signals—not a guarantee

Apple's Gatekeeper security guide says macOS checks outside-App-Store software for an identified developer, notarization, known malicious content and alteration. Its code-signing guide explains that signature validation supports that a build hasn't changed since the identified signer produced it; notarization is a separate Apple malware check.

Advanced readers can use Apple's documented read-only checks: spctl -vvv --assess --type exec "/path/to/App.app" for system-policy assessment, codesign -dvv "/path/to/App.app" for signer/timestamp details, and codesign --verify -vvv --deep --strict "/path/to/App.app" for bundle integrity. Copy the exact quarantined/original path, keep it quoted and compare Authority/TeamIdentifier with the developer's expected identity.

A rejected assessment, unexpected signer or altered bundle is a stop signal. A clean assessment is supporting evidence, not absolution: a validly signed publisher can ship a vulnerable or malicious build, notarization is time-bound to known threats, and documents, plugins or downloaded components may sit outside the main app's signature. Don't click Apple's Open Anyway while Intego evidence remains unresolved.

Use multi-engine evidence without turning private files public

VirusTotal's current documentation says standard submissions are shared between scanning partners, reports are shared with the community, and file contents may be available to premium customers. That sharing is valuable for redistributable installers and malware research; it's unsuitable for customer documents, source code, credentials, contracts, licensed assets or regulated data.

Do a hash lookup first when you already have a trustworthy SHA-256. If the exact public sample exists, its history can add context without uploading your copy. If it does not, submit only a sample you own or have permission and intent to share. VirusTotal's separate Private Scanning is an organizational paid capability and doesn't include the normal multi-antivirus partner verdicts; the standard free form doesn't become private because you're logged in.

Don't count logos. One precise detection with coherent behavior can outweigh many generic clean labels; several engines may share technology or copy late signatures. Read the detection names, file type, signer, prevalence, first/last submission, behavior and community notes. Use the report as evidence for Intego or the developer, not as a substitute for their analysis.

Intego's advertised malware form is stale: use the working support request

Intego's false-positive submission article still directs readers to a Malware Submission Page. On August 7, its advertised trailing-slash URL returned HTTP 404; the variant without the slash redirected to the homepage. Cached search content shows an older attachment form and 4 MB language, but we won't present a cached limit as a working current workflow.

Use Intego's live Submit a request page. It offers a request-type selector and carries the service-partner data-handling notice. Include the detection label, ONE/X9/Scanner build, definition timestamp, macOS version, original path category, source URL, expected publisher/version, SHA-256 and whether another official copy reproduces the result. Ask the team to classify the exact hash and provide its current approved sample-transfer route.

If the file is private, proprietary, credential-bearing, regulated or large, send metadata first and wait for handling instructions. Don't split a private document to bypass an old cached limit, paste confidential data into the request, or use an X5/X6-era sample email from an old manual. The broken vendor link is a documentation defect, not permission to improvise a risky transfer.

Intego ONE: Trust moves the item to Safe List

ONE's current guide is unusually clear: Trust indicates that you have confirmed the item isn't a threat; the item moves from Quarantine to Safe List and won't be analyzed in future scans. Safe List can also accept manual additions through the plus control or drag-and-drop. That convenience is why its audit matters.

If evidence is sufficient and work can't wait for a definition correction, trust only the exact file or application shown in the packet. Record its hash and the time you added it. Don't trust a parent folder to cover a changing build tree, Downloads or a shared directory; future unrelated content would inherit blind space.

When Intego or the developer provides an updated build/definition, select the Safe List item and Remove it. Then update, run a Custom scan of the exact item and check Antivirus History. If the item stays on Safe List, ONE is doing what you asked—skipping it—and a silent dashboard proves nothing.

VirusBarrier X9: Trusted Files can exclude an entire tree

The current X9 detection article says Trust adds the item to Trusted Files and warns to use it only when sure the file is safe. Repair attempts to remove malicious content and return the item; Delete removes it. A grey Quarantine button usually means X9 already isolated it automatically.

X9 can trust a file, folder or volume, and a trusted container covers every descendant. Treat that as a blast-radius control. One problematic compiler output doesn't justify excluding the entire repository; one backup artifact doesn't justify trusting the volume. Use an exact path, document the exception owner and set a removal date.

After the correction, remove the Trusted Files entry and rescan the exact item with current definitions. If it runs or has plugins/helpers, scan its enclosing application bundle and relevant created paths as well. Keep the log row that records trust removal and the completed clean scan; an empty quarantine panel isn't the receipt.

Free Scanner: Option-Restore returns the file and creates trust

The free VirusBarrier Scanner manual says holding Alt/Option changes Restore & Repair into Restore without Repair. The file returns to its original location and is added to Trusted Files. That's a false-positive-only route, not an undo button.

Because the free Scanner has no real-time protection, restoring the file leaves a wider time gap than in paid ONE/X9. Don't open it until the evidence is sufficient. Note its destination and hash, restore only the exact item, and keep macOS Gatekeeper active. A sandboxed Scanner also can't make claims about locations it lacks permission to inspect.

After definitions or the file update, remove it from Trusted Files and run a direct scan. If the item is a folder or volume, remember that the exclusion covered all descendants; review anything added while it was trusted. The free-versus-paid guide explains why repeated exceptions are a practical trigger for managed real-time protection rather than an expanding Trusted Files list.

Verify and restore an Intego false positive in ten steps

1. Keep the item quarantined. Don't open, restore, trust or delete the file while the evidence is incomplete; quarantine preserves the safest reversible state.
2. Record the exact detection. Capture the Intego generation, app and definition versions, detection name, original path, scan type, timestamp and every available action without exposing private content.
3. Update and rescan in quarantine. Install current application and definition updates, then rescan the quarantined item or original controlled scope before changing the exclusion state.
4. Verify source and publisher. Compare the acquisition route, expected developer, official download or App Store receipt, version and any publisher-provided hash; a familiar filename isn't enough.
5. Check signature and Gatekeeper evidence. For an application, inspect expected Developer ID, signature integrity and notarization or Gatekeeper state; treat positive results as supporting evidence, not a guarantee.
6. Decide whether the sample is shareable. Don't put customer data, credentials, source code, licensed assets, personal documents or regulated content into a public multi-engine service or ordinary upload form.
7. Use the working Intego support route. The support article's advertised malware form currently returns 404, so send the detection metadata through Submit a request and ask for the current approved sample-transfer method, especially for sensitive files.
8. Use the narrowest temporary exclusion. Only after sufficient evidence or vendor direction, Trust the exact ONE/X9 item or use the free Scanner's Restore without Repair; never trust a broad folder or volume for one alert.
9. Remove the exclusion after correction. Once definitions or the application are updated, remove the item from ONE Safe List or X9/free Trusted Files so the next scan actually examines it.
10. Prove the result with two receipts. Run a targeted scan and, when the file executed or could have spread, a Full Scan; keep clean history/log entries and escalate if detection returns or the source recreates the file.

The order prevents a circular proof. Trusting first makes the scanner quiet; quiet is then misread as clean. Removing the exclusion before the final targeted scan breaks that circle. When the item executed or could have created other content, the Full Scan and log/history receipt add the necessary wider scope.

Set a reminder for every temporary exception. Small teams should record owner, exact path/hash, reason, evidence, creation date and expiry. A permanent Safe List entry with no owner becomes a hidden security policy, even when it began as a reasonable emergency workaround.

If the detection returns, trace what recreated or changed the file

Compare the new SHA-256, path and timestamp with the original packet. A different hash may be a newly built or updated file; the same hash at the same path suggests the classification persists; the same hash appearing after deletion points to a source that restores it. Browser downloads, cloud sync, package managers, installers, login items and application updaters are common creators to document.

Stop opening the item and don't repeat Trust automatically. Scan the creator or original archive, check the official developer channel for a new build, and report the recurrence to Intego with both event times/hashes. If an application recreates a helper at launch, the helper alone may not be the real remediation target.

When the alert follows every definition update, verify that the exclusion really was removed and the scan actually covered the path. If it was, recurring detection is evidence—not an annoyance to suppress. Repair/delete a confirmed threat and run the wider workflow from the scan guide; use vendor support when protected files or repeated repair loops remain.

Can't quarantine or repair: Trust may be a bypass, never the verdict

A current May 2026 Intego article says macOS can prevent VirusBarrier from modifying certain files, including Time Machine backup content. It tells users to Trust the file and remove it manually. That instruction solves a product permission deadlock; it doesn't transform the detection into a false positive.

Before following it, record the exact path/detection/version, keep the item closed and trust only that item. Use the supported Finder/Apple/vendor route for ordinary data. For a system-protected path, managed Mac or unclear backup object, stop and ask Intego/Apple or the administrator; don't disable System Integrity Protection, rewrite ownership or edit backup internals blindly.

Then remove the Trusted Files entry, update definitions and scan the accessible source/original location again. X9 10.9.62 and later normally hides Time Machine backup volumes, as the scans guide explains. A current detection there therefore needs exact build/path evidence rather than an assumption that an old screenshot matches the present setup.

Developers and IT teams should treat false positives as release defects

A developer can shorten resolution by providing a reproducible clean build, immutable SHA-256, Developer ID/Team, notarization evidence, download URL, version, affected Intego detection/definitions and a minimal redistributable sample. Submit the exact released artifact rather than a locally rebuilt binary with different bytes. If the vendor corrects definitions, retest the original release hash and a clean install.

IT should centralize exceptions rather than letting every user trust a folder. Record business owner, scope, hash/signing requirement, ticket, approval, creation and expiry. Prefer an exact signed binary rule where the product supports it; ONE/X9 consumer interfaces are path/item oriented, so keep the scope narrow and audit after updates.

For sensitive software, negotiate a vendor support route before transfer and confirm who can access the sample. Standard VirusTotal's sharing model and Intego's visible service-partner notice both matter. The fastest false-positive fix isn't worth disclosing source code, customer records or credentials to an unintended corpus.