Is a Telnet Scan Finding a False Positive After Nmap Encryption Test?
After reviewing the following vulnerability scanning report: A security analyst performs the following test: Which of the following would the security analyst conclude for this reported vulnerability? - 
- 
Community Votes
58% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The exam tests whether you validate scanner output with a targeted test before acting on it; the trap is defaulting to 'compensating controls exist' any time Telnet appears, even when the analyst's own Nmap result contradicts the reported cleartext condition.
A vulnerability scanner flags a host's Telnet service as an insecure cleartext protocol, and the analyst's follow-up Nmap telnet-encryption test shows the service supports encryption. This page explains why SY0-701 treats that validated finding as a false positive (A) rather than a compensating control.
The most common wrong pick is D, because candidates reason that 'Telnet is always risky, so encryption must be a compensating control' — but the scenario's decisive evidence is the analyst's Nmap validation, which shows the scanner's cleartext-Telnet claim does not match the host's actual state.
Community Discussion (36 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The scanner reported the Telnet service on the host as an insecure cleartext protocol, and the analyst then ran a focused validation test — Nmap with the telnet-encryption NSE script — against that same service. The test output shows the Telnet server supports encryption, which directly contradicts the condition the scanner claimed (plaintext-only Telnet). A false positive is exactly this situation: a scanner finding that, when independently validated, does not reflect the real state of the asset. Because the question asks what the analyst would conclude about the reported vulnerability after performing the test, the validated result makes the report a false positive, and remediation should be driven by the analyst's evidence rather than the raw scanner alert. This report-then-test structure is the classic vulnerability-validation workflow that SY0-701 expects you to recognize.Why the Other Options Are Wrong
Option B, "a rescan is required," applies when a scan is incomplete, the host was unreachable, or authenticated scanning credentials failed — here the analyst already completed a targeted follow-up test, so another scan adds nothing. Option C, "it is considered noise," describes low-severity, low-value alerts that clutter a dashboard without representing a real exploitable condition; a Telnet finding is high-signal, not dashboard noise, so that label is a poor fit. Option D, "compensating controls exist," would only be correct if the vulnerability were confirmed on the host and a separate alternative control were mitigating it; the analyst's own telnet-encryption output shows the flagged cleartext condition is not what the scanner said it was, so there is no confirmed finding for a compensating control to offset. Selecting D second-guesses the analyst's validation data, which is the evidence the question hands you.Community Comment Notes
Support for option A comes from mr_reyes, who defines the term precisely as a scanner that "incorrectly identifies a vulnerability that doesn’t actually exist," and from dbrowndiver, who notes that "The presence of encryption changes the security profile of Telnet." The dissent is not unreasonable: Russell15 argues that "Telnet is still a risk by default," while another commenter insists that Telnet is inherently unencrypted and that encryption layered on it is merely a technique rather than a fix. Storcaks adds the sharpest counterpoint — the script only proves the server supports encryption, not that a client is required to use it. Those are valid hardening arguments for real-world environments, but the exam question asks what the analyst concludes about the reported vulnerability after the validation test, and the validation data is what the source scenario rewards.Official Reference
Exam Strategy
For any vulnerability-management scenario, identify which artifact is the evidence — here the analyst's Nmap test, not the original scanner alert. When the follow-up test contradicts the scanner's description of the host, choose the false-positive option; reserve 'compensating controls exist' for cases where the vulnerability is confirmed and a different control is explicitly mitigating it.
Frequently Asked Questions
Why is the Telnet finding a false positive instead of a compensating control?
Compensating controls apply when a real, confirmed vulnerability is offset by another control; here the analyst's Nmap test shows the reported cleartext condition does not match the host, so the report itself is wrong.
Does Telnet supporting encryption mean port 23 can be ignored in production?
No. The Nmap script only proves the server offers encryption, not that clients must negotiate it, so most exam and real-world guidance still prefers replacing Telnet with SSH.
Related Analysis
Practice All SY0-701 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SY0-701 Practice Test →
telnet-encryptionscript shows that the Telnet server supports encryption. Given that Telnet is typically insecure due to lack of encryption, the presence of encryption support indicates that the reported vulnerability might not be accurate. Therefore, the security analyst would conclude that the reported vulnerability is a false positive.