A file or program you trust was blocked or quarantined

Security software occasionally objects to something harmless. Telling that case apart from a correct detection takes a few minutes and a little method, and the order of the steps matters more than any single one of them.

The short version

Do not restore a quarantined file as a first move. Establish where the file came from, check whether the detection name describes a real category of software, and submit the file to the vendor if you believe it is wrong. A file you compiled or created yourself, or downloaded from the developer’s own site, is the most likely candidate for a false positive. A file that arrived by email, by message, or from a download site you had not heard of is the least likely.

What has actually happened to the file

When a product quarantines something, it usually moves the file into an isolated store, encodes it so that it cannot be executed, and records what was detected and when. The file is not deleted. That design exists precisely because detections are sometimes wrong, and the original can be put back.

The detection name shown alongside is worth reading rather than ignoring. Names generally take a rough form of platform, category and family — something along the lines of a Windows trojan of a named family, or a generic classification ending in a marker for heuristic detection. A specific family name suggests a signature match against known code. A name containing words such as generic, heuristic, suspicious or machine-learning suggests the file was judged on its behaviour or structure rather than recognised outright, and behavioural judgements are where false positives concentrate.

Why legitimate software gets flagged

It was newly compiled or is rarely seen. Reputation systems weigh how many other devices have seen a file. A program built yesterday, or downloaded by a few hundred people worldwide, has no reputation to draw on.
It is packed or obfuscated. Installers and commercial software frequently use compression and anti-tamper techniques that resemble the techniques malware uses to hide.
It does things malware also does. Automation tools, remote access utilities, key remappers, system tweaking programs, older game modifications and network scanners all legitimately perform actions that a scanner is designed to be suspicious of.
It is unsigned. Code signing certificates cost money, and small developers and open-source projects often do without. Unsigned code attracts more scrutiny.
It is genuinely a potentially unwanted application. Some software is not malicious but does bundle extras, change browser settings, or resist removal. Products differ on whether they block this category by default.

A sensible order of operations

Leave the file in quarantine while you think. Nothing is lost while it sits there, and a restored file that turns out to be malicious is a worse position than a delayed one.
Establish where it came from, honestly. Your own build output, or a download taken straight from the developer’s own site, is one thing. A link in an email, a file-sharing site, a cracked or repacked version of commercial software, or a download button on a site that mirrors other people’s software is quite another. If the origin is in the second group, the detection is probably doing its job.
Check the publisher, if the file is signed. On Windows, right-click the file, choose Properties, and look for a Digital Signatures tab; the signer’s name should match the developer you expect. On macOS, an application from an identified developer will open without the security warning shown for unidentified ones.
Compare against the developer’s published checksum where one exists. Many open-source projects publish a SHA-256 hash next to the download. If yours does not match, stop — the file you have is not the file they published.
Submit the file to the vendor as a suspected false positive. Every major vendor operates a submission process, usually reachable from its support site. This is the step that actually fixes the problem, because a corrected signature helps everyone who has the same file, not only you.
Only then decide about restoring. If you are satisfied the file is what you think it is, restore it and, if the detection returns, add a narrow exclusion for that specific file rather than for its whole folder or drive.

What an exclusion really does

An exclusion tells the product to stop inspecting something: a file, a folder, a file type, or a running process. It does not mark the item as safe — it makes the product blind to it. That distinction matters when choosing how wide to make one.

A narrow exclusion on a single executable you built yourself is a small, considered decision. An exclusion covering your downloads folder, your whole user directory, or an entire drive removes inspection from the places files most often arrive from elsewhere. Exclusions by file type are worse again, because a rule that ignores every file with a given extension applies to files you have never seen as much as to the one you were trying to use.

Keep a written note of every exclusion you add and why. On a shared or family computer this matters more, not less: a setting added a year ago to make one program work will not be remembered by whoever inherits the machine.

Situations where the answer is simply no

A detection on a cracked, repacked or key-generating version of commercial software is very unlikely to be wrong, and this is one of the most reliable ways for a home device to be compromised.
Instructions that tell you to turn protection off before installing something, or to exclude a folder before downloading into it, are a well-worn pattern. Genuine software does not require you to be unprotected during installation.
A message that appeared in a browser tab and told you a file is safe is not a security product speaking. The alerts page explains how to tell the difference.
Anyone who contacts you offering to resolve a detection by remote access is not helping. Report contact of that kind to Scamwatch, the National Anti-Scam Centre’s service.

Terms you will meet in the interface

False positive: A detection on a file that is not in fact malicious. Common enough to plan for, rare enough that it should not be your first assumption.
Quarantine: The isolated store described above. Items usually stay there until you act or until a retention period passes, so restoring later is normally possible but not indefinitely.
Exclusion, or exception: An instruction not to inspect a particular item. Narrow is safer than broad, and temporary is safer than permanent.
Reputation: A score derived from how widely and for how long a file has been seen across a vendor’s user base. New and rare files score poorly whether or not they are harmful.
Code signing: A cryptographic signature identifying who published a file and confirming it has not been altered since. Its absence is not proof of anything, but it removes a useful check.
Submission: Sending a sample to the vendor for analysis, either as a suspected false positive or as something you believe was missed.

If you genuinely cannot tell

The safest position is the one where the file stays in quarantine and you do without it. Most blocked files have an alternative: a different tool that does the same job, a version from a better-known source, or a feature already present in software you already have.

If the file matters and the source is legitimate, the developer’s own support channel is the right place to ask. Developers of small tools are usually aware of which scanners flag their software and will say so directly. General advice on staying secure at home, including how to think about software you are unsure of, is published by the Australian Cyber Security Centre at cyber.gov.au.