Vulnerability Management and Patch Management
This domain tests the difference between finding weaknesses and fixing them. Vulnerability management identifies and prioritizes CVEs on endpoints; patch management deploys missing updates. Exam questions often ask which profile setting performs a scan, which console view shows exposure, or why a patch task did not complete.
Vulnerability management
- A Vulnerability Scan profile defines scan type, schedule, and scope. Scans detect missing updates and vulnerable software, and results are tied to CVEs and severity.
- EMS dashboards show vulnerable endpoints, severity distribution, and affected software. Results can be filtered by endpoint group, severity, or CVE.
- Scan data is only useful if endpoints check in. Offline endpoints retain their last result, which may be outdated.
- Remediation can be driven by patch deployment or by manual action on the endpoint, depending on the finding.
Patch management
- A Patch Management profile enables patch scanning and deployment. The administrator reviews missing patches, approves them, and schedules deployment.
- Deployment options include maintenance windows and reboot behavior. A patch that requires a reboot is not fully effective until the reboot occurs.
- Patch management supports Windows endpoints and macOS where the profile and EMS version provide it; confirm platform support before promising coverage.
- Approval is a control point. Do not assume every missing patch is automatically deployed; unreviewed or unapproved patches remain pending.
Worked example
A critical CVE affects 200 Windows endpoints. A vulnerability scan shows 120 endpoints missing the relevant update. The administrator creates a patch deployment task, approves the vendor update, schedules it for a weekend maintenance window, and allows reboot. On Monday, 110 endpoints report success, 10 are offline, and 80 were never scanned because they had no patch profile. Reasoning: the vulnerability scan found exposure, but patch deployment required approval, a schedule, reboot completion, and the patch profile to be assigned.
Traps that cost marks
- Treating a vulnerability scan as a patch deployment; scanning does not install updates.
- Forgetting that offline endpoints do not receive the patch task until they check in.
- Scheduling a patch that requires a reboot but not allowing the reboot, then marking it successful.
- Leaving patches unapproved and expecting automatic remediation.
- Missing the patch management profile on some groups, creating invisible coverage gaps.
Monitoring, Logging, and Troubleshooting
This domain tests whether you can use EMS dashboards, logs, and endpoint diagnostics to isolate a failure. Questions often present a symptom such as an endpoint not appearing, a profile not applying, or a ZTNA tag missing, and ask for the first or most likely check.
Monitoring
- EMS dashboards show endpoint online/offline status, registration counts, license usage, vulnerability exposure, patch status, and ZTNA/compliance state.
- Task Monitor shows deployment, scan, and patch job progress. Audit logs record administrative changes.
- EMS can forward logs to syslog or FortiAnalyzer. Retention and forwarding must be configured; they are not automatic.
- FortiGate EMS connector status confirms whether the gateway is communicating with EMS.
Troubleshooting registration and check-in
- Confirm the FortiClient service is running and the endpoint can reach EMS on TCP 8013. Test with a port check from the endpoint subnet.
- Verify DNS resolution, correct EMS address in the installer/profile, valid invitation, license entitlement, and a supported FortiClient version.
- Check time synchronization and certificate trust. Time skew breaks TLS and SAML.
- On the endpoint, use FortiClient diagnostics and collect logs. On EMS, use the log collection/diagnostic tools before restarting services.
Troubleshooting policy and tags
- If a profile is not applying, confirm registration, group assignment, profile assignment, and the last check-in time.
- If a ZTNA tag is missing, confirm the compliance rule is assigned and evaluated, and that the endpoint has checked in since the rule changed.
- If FortiGate enforcement fails, confirm the EMS connector is up and the tag name matches the firewall policy exactly.
Worked example
A new endpoint does not appear in EMS. The administrator first confirms the FortiClient service is running, then tests TCP 8013 from the endpoint to EMS. The port is blocked by a local firewall rule. After allowing 8013, the user re-enters a valid invitation, the endpoint registers, and the profile applies. Reasoning: registration requires both a listening EMS and a reachable path; the invitation was valid but the network path was not.
Traps that cost marks
- Troubleshooting only the endpoint while ignoring EMS service health, license, and logs.
- Overlooking NTP or certificate trust, then chasing registration as a FortiClient bug.
- Assuming logs are retained or forwarded without configuration.
- Restarting EMS services before collecting logs and losing evidence.
- Checking a tag in EMS but not verifying the exact tag reference in the FortiGate policy.