Questions people ask before they start

ConfigSentry is a FortiGate-focused audit and reporting platform for reviewing firewall configuration risk, posture, and control gaps. It is designed to turn a FortiGate configuration into structured findings, remediation context, and report output for technical and governance audiences.

ConfigSentry currently supports Fortinet FortiGate firewalls. The current support baseline documented in the product terms is FortiOS 6.4.5 and later, and the exact supported models and FortiOS versions are published on the Supported Platforms page in the knowledge base.

Yes. The product and pricing are positioned per FortiGate firewall or cluster, so an HA pair or cluster is treated as one licensed review target rather than separate appliances for each member.

Yes. VDOM-aware FortiGate configurations are supported in the audit workflow, and the runtime metadata used by the audit engine includes selected or detected VDOM scope for the run.

Yes, provided the FortiGate is otherwise supported and you can supply a valid configuration through manual upload, direct SSH retrieval, or an approved collector-based workflow.

No. Firewall policy is a major part of the review, but the platform also looks at management exposure, logging posture, segmentation-impacting access, objects, services, interfaces, and wider configuration signals that affect operational risk.

It is designed for network engineers, firewall engineers, security engineers, consultants, and organisations that need clearer FortiGate review output, repeatable evidence, and less manual cross-checking before audit or remediation work.

No. You can start with a manual FortiGate configuration upload and run an on-demand audit without giving the platform live retrieval access first.

Yes. Manual upload is the normal starting point for one-off audits and first evaluations because it lets you test the output against a real FortiGate configuration without deploying a collector first.

Yes. The documented product workflows include manual upload, automated collection through an on-premise collector, and direct SSH auditing for supported appliances. That means a collector is useful for recurring review, but it is not the only way to retrieve a configuration.

No. The platform is designed for read-only review and reporting. It analyses configurations and produces findings and reports, but remediation and production change remain under your own change-control process.

An audit can start from a manual upload, from direct SSH retrieval against a supported appliance, or from a collector-based workflow when you want scheduled or lower-touch recurring review.

One audit produces prioritised findings plus both the engineer report and the executive report from the same audit run. The engineer view is intended for technical follow-up, while the executive view is intended for posture, priority, and governance conversations.

The audit does not complete successfully. Depending on the failure reason, you may need to upload the configuration again, let the collector recollect it, or correct the input before retrying. If a queued audit cannot start because its temporary decrypt key is unavailable, the status may show retry required.

No. Failed audits do not consume a credit.

Yes. Engineer and executive outputs can be exported and used for review and evidence support, but they remain advisory outputs rather than a compliance certificate.

No. Findings and reports are advisory outputs only. A qualified engineer still needs to validate findings and make remediation decisions.

Use the How It Works and Sample Reports pages for the workflow and output detail.

Yes. The platform is designed for retrieval, analysis, and reporting, not for pushing configuration changes back to the firewall. That applies whether the audit starts from manual upload, direct SSH retrieval, or a collector workflow.

A self-service Data Processing Agreement is not currently available during the early free trial. If your organisation requires a DPA or supplier security review before uploading production firewall configurations, please contact Secdit first.

Only if you are authorised to do so and your organisation is comfortable with the current trial terms. For early testing, we recommend using a lab, test, sample, or sanitised configuration where possible.

They can, depending on how the firewall is configured. Configuration files may include usernames, email addresses, VPN identities, hostnames, IP addresses, comments, or other environment-specific information. Treat them as sensitive.

For the normal hosted audit path, secret material such as passwords, private certificates, and keys is stripped before queueing. If a manual audit is run with "Do not save results on website" selected, the configuration is processed in memory only. See the Security and Data Handling page for the fuller handling path.

For the normal hosted path, the stripped configuration is generally processed within a few minutes and then removed from the queue database. The Security and Data Handling page covers the fuller retention context.

Yes. Deleting audits, reports, or related account data removes them from the live database immediately. Periodic database backups may still retain deleted data for up to 30 days as part of normal resilience and recovery processes.

Audit results, findings, reports, audit history, and related account metadata may remain as part of the service until deleted. Those outputs can still contain sensitive security information about the reviewed environment.

Not always. Manual uploads, direct SSH retrieval, scheduled direct SSH runs, and collector-triggered audits can be queued when workers are busy or health limits delay processing. In that case the audit is accepted first and starts automatically when capacity is available.

Retry required means the queued audit could not start because its temporary decrypt key was unavailable before processing began. In that situation you may need to upload the configuration again or let the collector or retrieval workflow collect it again.

Yes. MFA helps protect access to audit history and config-derived findings, especially in shared accounts. The current sign-up flow enables email-based MFA by default, and the application also supports TOTP as a backup MFA method.

Yes. The collector documentation states that where a setting is marked Enter Locally, the secret is intended to remain on the collector host instead of being stored as a website-managed secret value.

ConfigSentry is hosted with Hetzner in Nuremberg, Germany.

Yes. Audit templates help control which checks run for a given review, so teams can manage the rule set used for a particular audit workflow.

Use the Security and Data Handling page for the trust model and handling summary, and the collector knowledge-base pages if your review needs host, network, or local-secret detail.

ConfigSentry is currently being offered as an early free trial. Every new account receives 2 included audit credits on sign up. Additional evaluation credits and licenses may be available during onboarding. The intended evaluation path is to run a FortiGate audit first rather than relying on brochure-only product claims.

One audit credit covers one full audit and produces both the engineer report and the executive report from that same audit run.

Use audit credits for one-off review, spot checks, or pre-audit validation. Use licenses when you want recurring scheduled audits, collector-based retrieval, or faster ongoing monitoring in environments where configuration drift matters.

Yes. A support portal is available to help with product issues. There is no published SLA, but issues are worked on as soon as possible.

No. The normal path is to create an account, run a real audit with included credits, review the findings and reports, and only then decide whether you need more credits or a recurring license.

It reduces reliance on manual exports and supports lower-touch recurring audit workflows. The collector documentation also supports scheduled collection and syslog-triggered collection when you want configuration-change events to trigger a targeted run.

The collector knowledge base currently documents supported collector workflows for Windows, Linux, and FreeBSD. Those guides cover host requirements, installation, local settings, service behaviour, and update workflows.

Usually no. For a one-off review, manual upload or direct SSH auditing is the lighter starting point. A collector becomes more useful when you want scheduled retrieval, recurring review, or syslog-triggered collection inside your environment.

No. Findings and reports can support control review and evidence gathering, but they do not by themselves certify compliance or act as a certification or assessor substitute.

Use Audit Models for operating fit, Security and Data Handling for trust detail, and Compliance Alignment if you want the governance-oriented view of how findings support control conversations.