Nessus Essentials now caps you at five hosts and thirty days. That limit lands before you install anything, because it decides what you are allowed to point the scanner at and how long the free licence lasts. The sixteen-host, never-expires Essentials that most Nessus guides describe is gone.
What follows is the full path to install Nessus on Kali Linux: a download URL that does not rot when Tenable ships a new build, a checksum you can actually verify, the service start Kali leaves to you, the activation wizard including its new email verification step, and a first Basic Network Scan with real findings. If you are building the box from scratch, the step-by-step Kali installation covers the base system. Every command here was run on a clean Kali rolling install (kernel 7.1.5) with Nessus 10.12.4 in September 2026.
What the free Essentials licence covers
Tenable split the free tier in two. Essentials is the no-cost entry point, Essentials Plus is the paid upgrade that used to be closer to what Essentials was. The numbers below come from the Nessus Essentials product page and match what the scanner reports on its own About screen.
| Item | Nessus Essentials | Nessus Essentials Plus |
|---|---|---|
| Hosts you can scan | 5 IPs | 20 IPs |
| Plugin feed | 30 day delay | Real time |
| Licence length | 30 days, scan data not retained after expiry | 1 year, scan data retained |
| Reporting and data export | Not included | Basic PDF and HTML |
| Permitted use | Personal, educational, non-commercial | Personal, educational, non-commercial |
| Cost | Free | 199 USD per year, free for verified students and educators |
The thirty day plugin delay is the part that surprises people. A fresh install compiles the plugin set as it stood a month ago, so anything published in the last four weeks is not in your feed. For a home lab or a study box that is fine. For anything where the report matters, it is not.
Neither tier is licensed for commercial work. Tenable restricts Essentials and Essentials Plus to personal, educational and non-commercial use, so consulting engagements and anything client-facing need Nessus Professional. That matters more on a Kali box than on most, because the people installing Nessus on Kali are frequently doing paid assessment work.
Compliance auditing is the capability the free tier actually loses. The licence the scanner receives carries "enable_compliance":"false", and the template chooser’s COMPLIANCE group holds seven entries, every one of them wearing an UPGRADE badge: Audit Cloud Infrastructure, Internal PCI Network Scan, MDM Config Audit, Offline Config Audit, PCI Quarterly External Scan, Policy Compliance Auditing and SCAP and OVAL Auditing. Badges outside that group are softer than they look. Credentialed Patch Audit carries one and still opens a normal scan editor on an Essentials licence.
The five host cap is enforced when a scan runs, not just recorded in the licence. Every scan writes the clamp to the log twice:
Reducing max_hosts to 16 (Essentials restriction)
Reducing max_hosts to 5 (license restriction)
max_hosts: 5, max_checks: 4The old sixteen host tier is still in the code path. The licence takes it down to five on the way past. Two things soften the cap: hosts found by a discovery scan never count against it, and a host you have not scanned in 90 days drops off the count.
Size the Kali host before you start
Nessus is heavier than its install footprint suggests. The package itself is under 100 MB, but the first start pulls the plugin feed and compiles it, and that is what sets the spec. Tenable publishes scanner hardware requirements of 4 cores at 2 GHz, 4 GB RAM with 8 GB recommended, and 30 GB of disk on top of whatever the operating system uses. Treat those as the floor.
What this box actually consumed sits inside them. The compiled plugin tree reached 4.2 GB across 325,514 files, /opt/nessus as a whole reached 12 GB once the compiled databases were written, and nessusd reported a 6.6 GB memory peak across the compile and the first scan on a machine with 7.8 GB of RAM. Plugin compilation and scan concurrency are the two things that move that number, so size for the busier of the two rather than for an idle daemon.
The lab VM ran 4 vCPU, 8 GB RAM and an 80 GB disk, which is a floor for following along rather than a production recommendation. Give it noticeably less RAM than the compile wants and you are leaning on swap to get through the first start.
One value repeats through the rest of this guide, so export it once and paste everything else as-is:
export SCANNER_IP="192.168.1.139"Swap in the address of your own Kali box. The variable only lives for the current shell session, so re-run it if you reconnect or drop into sudo -i.
Download Nessus without pinning a version
Tenable publishes a latest alias for every package it ships. Use it and the command keeps working after the next release, which is the whole reason not to copy a versioned URL out of an old guide. Kali is Debian based, so the debian10_amd64 build is the right one:
cd /tmp
curl -LO "https://www.tenable.com/downloads/api/v2/pages/nessus/files/Nessus-latest-debian10_amd64.deb"The alias is a redirect, and the response header tells you which build it actually handed over:
curl -sI "https://www.tenable.com/downloads/api/v2/pages/nessus/files/Nessus-latest-debian10_amd64.deb" | grep -i content-dispositionThe filename in that header is the real version behind the alias:
content-disposition: attachment; filename="Nessus-10.12.4-debian10_amd64.deb"The same downloads API publishes a SHA256 for every file, so there is no reason to skip the integrity check. Pull the published hash for the Debian build:
curl -s https://www.tenable.com/downloads/api/v2/pages/nessus | python3 -c "
import json,sys
for group in json.load(sys.stdin)['releases']['latest'].values():
for f in group:
if 'debian10_amd64' in f['file']:
print(f['sha256'], f['file'])
"Then hash what you downloaded and compare the two strings:
sha256sum Nessus-latest-debian10_amd64.debBoth printed the same digest on this download, which is what a clean transfer looks like:
53daa823f50967ffa6cff74d205739a54719152a844f209888c603e69f9aadf8 Nessus-latest-debian10_amd64.debDownload, checksum and a listening daemon, in the order you will run them:
Install the Nessus package on Kali Linux
Install through apt rather than dpkg -i so any missing dependency resolves in the same pass. The leading ./ matters, because without it apt treats the argument as a package name:
sudo apt install -y ./Nessus-latest-debian10_amd64.debThe post-install script runs a FIPS self-test over the bundled OpenSSL provider, unpacks the scanner core, then prints where to go next:
Setting up nessus (10.12.4) ...
HMAC : (KAT_Integrity) : Pass
SHA2 : (KAT_Digest) : Pass
AES_GCM : (KAT_Cipher) : Pass
RSA : (KAT_Signature) : Pass
[... about 30 FIPS self-test lines in total ...]
name: OpenSSL FIPS Provider
version: 3.1.2
build: 3.1.2
INSTALL PASSED
Unpacking Nessus Scanner Core Components...
- You can start Nessus Scanner by typing /bin/systemctl start nessusd.service
- Then go to https://NESSUS_HOSTNAME_OR_IP:8834/ to configure your scannerThe last line is worth reading carefully. Older builds printed the machine’s own hostname there, which is where the https://kali:8834 URL that fills forum posts and search results came from. Current builds print a placeholder instead, and the reason that change matters is covered further down.
Start nessusd, because Kali leaves it disabled
Straight after the install the unit is present but dormant. Check it before you go looking for a web interface that is not listening:
systemctl is-enabled nessusd
systemctl is-active nessusdOn a fresh install both answers are negative:
disabled
inactiveThat is Kali policy rather than anything Nessus did. The package’s postinst does call deb-systemd-helper enable, but the distribution ships a catch-all preset that overrules it:
cat /usr/lib/systemd/system-preset/99-default.presetSeven lines, one of which does the work, and it applies to everything you install:
# Kali specific policy to disable all services by default
#
# If you don't want this, you can "disable" this file this way:
# sudo mkdir /etc/systemd/system-preset
# ln -sf /dev/null /etc/systemd/system-preset/99-default.preset
disable *.serviceThe file belongs to base-files, so no package can opt out of it, and the comments spell out the supported override if you want Kali to behave like Debian. Leave it alone and enable the unit yourself, in one command, so it also survives a reboot:
sudo systemctl enable --now nessusdThis is the step that finally writes the wants symlink the preset held back:
Created symlink '/etc/systemd/system/multi-user.target.wants/nessusd.service' -> '/usr/lib/systemd/system/nessusd.service'.Confirm the daemon is bound before you open a browser:
sudo ss -tlnp | grep 8834It listens on all interfaces over both address families, so nothing extra is needed to reach it from your LAN:
LISTEN 0 1024 0.0.0.0:8834 0.0.0.0:* users:(("nessusd",pid=12878,fd=13))
LISTEN 0 1024 [::]:8834 [::]:* users:(("nessusd",pid=12878,fd=21))Read that as exposure, not just convenience. At this point the scanner has no credentials at all, because the administrator account does not exist until the wizard runs. Anyone on the network who reaches port 8834 before you do can claim the scanner by completing the setup themselves. Do the wizard promptly on a network you do not control, and narrow the listener afterwards; there is a section on that below.
Kali ships with no firewall rules and no ufw binary, so a guide that tells you to run sudo ufw allow 8834 fails on a stock install. Check the real state with sudo nft list ruleset; on a clean box it prints nothing at all, which means port 8834 is already reachable. If you have added rules of your own, that is the ruleset to edit.
Open the web interface, and why https://kali:8834 fails
Older Nessus builds ended their install output with https://kali:8834/, and that string has been copied into guides, forum answers and search queries ever since. It works on the Kali box itself and nowhere else. The reason is in /etc/hosts:
cat /etc/hostsDebian maps the machine’s own hostname to a loopback address, not to its LAN address:
127.0.0.1 localhost
127.0.1.1 kali
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersSo kali resolves to 127.0.1.1 on the scanner and to nothing anywhere else. From any other machine, use the address instead:
echo "https://${SCANNER_IP}:8834/"Error: “curl: (6) Could not resolve host: kali”
Your workstation has no entry for kali and no DNS record to find one. Either use the IP address, or add the mapping to your own machine’s hosts file if you want the name to work. Nothing on the scanner needs changing.
Error: “SSL: certificate subject name ‘kali’ does not match target hostname”
Nessus generates its own certificate on first start and signs it with a private CA, using the machine hostname as the common name. Browsing to the IP address therefore trips both a name mismatch and an untrusted issuer. Inspect it and the whole picture is there:
echo | openssl s_client -connect "${SCANNER_IP}:8834" 2>/dev/null | openssl x509 -noout -subject -issuer -datesThe common name is the hostname, the issuer is Nessus itself, and the certificate is good for four years:
subject=O=Nessus Users United, OU=Nessus Server, L=New York, C=US, ST=NY, CN=kali
issuer=O=Nessus Users United, OU=Nessus Certification Authority, L=New York, C=US, ST=NY, CN=Nessus Certification Authority
notBefore=Sep 17 21:04:36 2026 GMT
notAfter=Sep 16 21:04:36 2030 GMTAccepting the browser warning is fine on a lab scanner. If the box is shared, replace the certificate through Settings then Custom CA, or put a reverse proxy in front of port 8834 and terminate a trusted certificate there. Nessus flags its own self-signed certificate during a scan, which you will see for yourself further down.
Load the URL and the setup wizard takes over. Nothing has been configured yet, so this is the first screen every install shows:
Activate Nessus Essentials
Click Continue and the wizard asks how you are deploying. Six options are on that screen, covering purchased instances, Expert and Professional trials, the Essentials Plus education path, and linking the scanner to another Tenable product. Pick Register for Nessus Essentials for the free tier.
The next screen collects a name and an email address and mails you an activation code. If you already have a code, the Skip button below the form takes you straight to the entry field.
This is where the flow differs from every older guide. On a first registration the wizard stops on a Verify Email screen and waits: Tenable sends a verification link to the address you entered, and the code is not issued until you click it. Open the inbox, follow the link, then come back to the browser tab and continue. Once the address is verified the wizard shows the activation code directly on a License Information screen instead of making you fish it out of a second email.
After the code comes the administrator account. There is no default login to change later, so this username and password are the only way into the interface:
Submitting the account kicks off the plugin download and compile, and the browser sits on a single Initializing screen for all of it. On this 4 vCPU VM the log shows the plugin update starting at 00:24:00, finishing at 00:24:19, and the service reporting ready again at 00:26:55. Just under three minutes. The feed arrives as one compressed archive (all-2.0.tar.gz), so a slow link stretches the first part considerably; the 4.2 GB plugin tree and the compiled databases are produced locally from it.
Watch it from the shell rather than the browser if you want to know it is alive. The plugin directory grows steadily and the service logs a restart when the compile finishes:
watch -n 30 'sudo du -sh /opt/nessus/lib/nessus/plugins'
sudo tail -f /opt/nessus/var/nessus/logs/nessusd.messagesWhen it is done the wizard drops you at a normal login page and the scanner is ready to use:
Settings then About is worth a look straight away. It shows the licence you actually got, including the host count, the plugin feed delay and the expiry date you now need to diary:
Register from the command line instead
The wizard is optional. On a headless scanner, or when you are rebuilding a box you have already registered once, nessuscli does the same job without a browser. Feed it the activation code:
sudo /opt/nessus/sbin/nessuscli fetch --register XXXX-XXXX-XXXX-XXXX-XXXX
sudo /opt/nessus/sbin/nessuscli adduser nessusadminRegistration triggers the same plugin download, so expect the same wait. Two subcommands are useful afterwards. The first confirms the scanner can reach the update servers, the second prints which code the install is running under:
sudo /opt/nessus/sbin/nessuscli fetch --check
sudo /opt/nessus/sbin/nessuscli fetch --code-in-useA healthy scanner answers both without complaint:
Checking...
Updates are configured properly
Checking...
This scanner is using the following Activation Code: XXXX-XXXX-XXXX-XXXX-XXXXFor an air-gapped scanner, nessuscli fetch --challenge prints the challenge string. Exchange it at plugins.nessus.org/v2/offline.php for a licence file, then feed that file to fetch --register-offline.
Run your first scan
Scan only what you own or have written permission to test. A Nessus scan is loud, it authenticates where it can, and on someone else’s network it is trouble. If you need targets, stand up deliberately vulnerable ones: the DVWA web application lab gives you something legal to point it at, and the Proxmox pentest lab build covers the wider setup.
From My Scans, choose New Scan, then Basic Network Scan. It needs two things: a name and a target. Targets accept hostnames, single addresses, CIDR notation or a comma-separated list.
Save it, then launch it from the scan list. The scan used here pointed Nessus at its own host, which is the smallest honest test you can run and still get a real report. It ran with 315,795 plugins loaded, finished in six minutes, and returned 67 distinct findings across 91 detections.
Almost all of that is informational: service detection, installed package inventory, SSH and TLS capability listings. Exactly one finding came back Medium, and it is the scanner complaining about itself. Plugin 51192, SSL Certificate Cannot Be Trusted, CVSS 6.5, against port 8834 on the Nessus web interface, with the plugin output naming the CN=kali certificate from earlier.
That is a useful first result to sit with. It shows what a finding looks like end to end, description, solution, CVSS vector, affected port, and it is a real issue rather than a demo. Fix it the way the plugin says, by putting a trusted certificate on 8834, and the scan comes back clean.
The resource cost is worth checking once the scanner is live, because it does not shrink after the compile:
Nessus tells you what is wrong with a host. Working out what is reachable in the first place is a different job, and Nmap scanning on Kali is the faster tool for that pass. Confirming a finding is exploitable is a third job again, which is where Metasploit Framework comes in.
Lock the console down once setup is done
The wizard is finished and the admin account exists, so the interface no longer has any reason to answer the whole network. Pin it to loopback:
sudo /opt/nessus/sbin/nessuscli fix --set listen_address=127.0.0.1It restarts the web server on its own and says so, and the daemon comes back bound to loopback only:
Successfully set 'listen_address' to '127.0.0.1'.
The Nessus web server will be restarted.
LISTEN 0 1024 127.0.0.1:8834 0.0.0.0:* users:(("nessusd",pid=53516,fd=18))Reach it over an SSH tunnel after that. Run this from your workstation, where SCANNER_IP needs setting as well:
ssh -L 8834:127.0.0.1:8834 kali@"${SCANNER_IP}"Leave that session open and browse https://127.0.0.1:8834/ locally. The certificate warning does not go away, because the certificate still claims the name kali and you are now asking for a loopback address, but the console is off the network. Read the setting back with nessuscli fix --get listen_address and set it to 0.0.0.0 again if you later want the interface reachable directly.
Removing Nessus and reclaiming the disk
A first compile plus one scan left /opt/nessus at 12 GB on this box, which is real disk on a laptop-sized Kali install. A thirty day licence also means plenty of people install this once for a course and never open it again. Stop the service first so nothing is mid-write:
sudo systemctl disable --now nessusdThen purge the package:
sudo apt purge -y nessusPurging removes the binaries and the unit file, and the package’s postrm also deletes two compiled plugin databases, plugins-code.db and plugins-desc.db. Plenty survives that: the raw plugin source tree, plugins-attributes.db at 2.1 GB, and timestamped duplicates of the two files the script does remove. Check what is still there and clear it deliberately:
sudo du -sh /opt/nessus
sudo rm -rf /opt/nessusKeeping that directory buys less than it looks like. The plugin sources survive the purge but the two compiled databases the postrm targets do not, so a reinstall rebuilds them either way, and it still needs a valid activation code. On the free tier that means registering again once the thirty days are up, and a fresh Essentials licence does not carry your old scan results across. Essentials has no export either, so anything worth keeping has to come out of the web interface by hand before the directory goes. Otherwise delete it and take the 12 GB back.
