1. Current Model and Capacity
CPU/memory utilization, session counts, internet capacity and enabled security services are key inputs for deciding whether the current appliance remains suitable.
CPU/memory utilization, session counts, internet capacity and enabled security services are key inputs for deciding whether the current appliance remains suitable.
Review which security services are actually used, such as IPS, web filtering and application control. Unnecessary or missing coverage can be clarified before quotation.
Manufacturer support status and intended service life should be considered. If hardware replacement is approaching, a license-only renewal may not be the most suitable technical or commercial option.
The decision should consider performance, security services, connectivity, growth and total cost of ownership.
Actual sizing, licensing, security or architecture decisions should be based on the existing environment, vendor support conditions and project requirements.
No. The guide explains general evaluation criteria. Actual product, license or architecture decisions should be based on the existing infrastructure and a requirements assessment.
User/device counts, current products or infrastructure, capacity, license terms and expected growth information can speed up the quotation process.
Renewal requires model, serial number, contract expiry and actually used services. Support, updates, threat services and cloud features may represent separate entitlements. Do not infer current packaging or duration from historical purchases. HA members, spare devices and growth can affect scope and cost.
Compare current entitlements, used features and next-period needs in three columns. Verify the second HA member and support scope with the vendor. After renewal, check entitlement visibility and used services; a new package does not automatically mean identical coverage.
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Portal is active but signatures are stale | Time, DNS, internet access or synchronization may be faulty. | Review update results, signature date and entitlement together. |
| Expected legitimate operation is blocked | Rule scope or exceptions may match incorrectly; disabling the entire control hides the cause. | Inspect decision logs for one test identity and resource, and reproduce the condition in a pilot. |
| Access persists after policy changes | Existing sessions, tokens or alternate access paths may have different enforcement timing. | Test new and existing sessions separately; verify that direct access cannot bypass enforcement. |
| Alert exists but cannot be investigated | Missing fields, clock differences or collection gaps can prevent correlation. | Match source and central records, and demonstrate end-to-end traceability. |
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. A test environment that does not reflect production can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Cost includes more than purchase price or a monthly resource bill. Licensing scope, storage, egress, backup, support, operating effort and disruption impact are separate items. Compare equal service levels, capacity and time periods; a cheaper option may exclude an obligation. Compare forecast and actual spending by resource or business unit. Assess underuse risk for commitments and uncontrolled growth for flexible models. Verify pricing and licensing conditions against official documents at decision time.
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
This guide is based on evaluation criteria used by Doz Teknoloji's technical team in enterprise IT projects.
About Doz TeknolojiFortiGate serial number, FortiCare/FortiGuard registration status, contract scope and pre-renewal checks were cross-checked against current Fortinet documentation.
To reduce the risk of renewing the wrong device, contract or service coverage.
Content and primary sources were reviewed again.
Continue with the relevant technical guide, product/licensing page or project scenario.
Explore the related service and solution pages to plan implementation.
Share your current infrastructure, users or workload information so product, licensing or project scope can be clarified around your requirements.
Start a Technical Request