In Review
27Under consideration
Add API endpoints to list and trigger automations
We would like API support for automations so we can integrate them into our own workflows and orchestration processes. Specifically, it would be helpful to have: An endpoint to list all automations available in our account An endpoint to trigger an existing automation through the API Clear documentation explaining how automation related API functionality works
Screenshots in tickets
When submiting a ticket through “Open Ticket” there is no option to add screenshots or post more comments :) In here: https://app.halosecurity.com/user/support/ticket?id=xxxxxx
Automated Delivery of Executive Summary Reports via Email
Request to enable automatic delivery of an Executive Summary Report via email. This report would contain only high-level security metrics such as overall risk score, number of scanned assets, vulnerability counts, and risk trends. This option would provide us with a convenient way to share security posture insights with executive teams.
Add “Mitigated” as a Third Acknowledgement Reason for Issues
We would like the ability to acknowledge an issue using a third reason in addition to the current Acceptable Risk and False Positive options. Today, when we acknowledge an issue, we have to classify it as either something we accept as risk or something we believe is a false positive. However, there are cases where the finding is not a false positive, and we are not simply accepting the risk. Instead, we have reviewed the issue and put compensating controls or other mitigations in place to reduce the actual exposure. We would like a new acknowledgement reason such as “Mitigated” to represent this scenario. This would allow us to clearly distinguish between: -False Positive, the finding is not valid or not exploitable. -Acceptable Risk, we understand the risk and are choosing to accept it. -Mitigated, the finding may still appear in scans, but controls are in place to reduce or address the risk.
Track and Display “First Detected Date” for Identified Technologies
The current Technology section lists technologies, versions, risk ratings, and CVEs per target, but does not record when a specific technology was first detected. As a result, it can be hard to determine whether a technology is newly introduced or has been present for some time.
Add "First Seen Date" for Discovered Hostnames/Subdomains in Dashboard & CSV Exports
Currently, domain discovery displays active hostnames/subdomains but does not indicate when each asset was first observed as publicly accessible. It would be nice to have the visibility into when a domain or subdomain was initially discovered. This would help with tracking changes in asset exposure over time, identifying newly emerged or reappearing infrastructure, and supporting incident response.
Jira Integration at Partner (Parent) Account Level
As a partner managing multiple child accounts, we would like the ability to configure the Jira integration at the parent account level. Currently, the integration must be set up individually per child account, which can complicate centralized issue tracking. This feature would allow events and scan findings from child accounts to generate Jira tickets through a single integration configured on the parent account. This would be a valuable addition for resellers and MSSPs who require unified alerting and ticket management across their customer base.
Allow Custom Timezone Selection for Scan Scheduling
Currently, all scan scheduling and timestamps within Halo Security are displayed in UTC by default. This can create confusion for users operating in different time zones, especially when planning maintenance windows or interpreting scan histories. Requesting a feature that allows users to select their preferred time zone (e.g., Central Time) for viewing and configuring scan schedules. This would simplify time conversions and improve usability for teams managing scan timing across various regions.
Integration with CrowdStrike
This integration will enable ingestion of Halo Security’s external attack surface and vulnerability data into the CrowdStrike platform to enhance threat visibility and response.
PCI tracking on a per-target basis
It would be great to have a dashboard for ASV scans that displays all domains or IPs or Targets that have passed/Failed the scan, along with their next due date including reminders.
In Progress
8Actively being built
Ability to Tag issues on Targets
We have several Hundred Targets, and often Clients will come to us with their own reports. Also, different teams are responsible for resolving issues on specific targets but not others. Is it possible to tag specific issues on targets so we can say “This is reported By Client X and should be tracked” or “This is also found on Security Scorecard, so fixing this is a double dip”
Integration with Fortigate
Integrate with Fortinet to pull in/retrieve records.
Integration with Axonius
An integration with Axonius would help up with asset management. This platform allows us to discover, track, and manage all assets across our IT and security environment. Reference: https://www.axonius.com/
Support auto-tag or default-tag for parked domains
For domains parked at a registrar (e.g. GoDaddy), please give us some way to automatically/default tag those targets. That way we can keep an eye on them in case a site does pop up at those domains.
Integration with Meraki
For environments using Meraki-managed networks, public IPs and routes can change due to DHCP, uplink failover, or SD-WAN policies. Currently, such changes must be manually synced into Halo. With a Meraki API integration, Halo could automatically stay up to date on this.
Integration with Linear Issue Tracking
Description: Request to add a native integration between Halo Security and Linear (https://linear.app/) to streamline vulnerability management workflows. When Halo Security detects a new issue or vulnerability, the integration should automatically create a corresponding Linear issue with key details (target, severity, summary, remediation notes, and a link back to the Halo finding). Status updates and closures in Halo should sync back to Linear, ensuring both systems stay in sync. Use Case: Customers and internal teams using Linear for engineering and security operations can manage vulnerabilities directly from their existing workflow without manual duplication or exports from Halo. Requirements: Create Linear tickets automatically from new Halo issues based on configurable severity or tag filters Sync issue status, notes, and remediation updates bi-directionally Allow mapping of fields between Halo and Linear (e.g., severity → priority) Support linking back to the Halo Security finding from Linear Include authentication and workspace configuration options within the Halo Integrations settings Value / Impact: Eliminates manual ticket creation for vulnerability triage Reduces missed issues and improves remediation tracking Increases Halo’s integration coverage and appeal for teams already using Linear
Integration with Telegram
Integrate with telegram for event/alert triggers. Messages could include critical details like: Target affected Issue title and severity Scan name or time Link back to the Halo Security dashboard
Scheduled executive report
We use Halo to meet our PCI-DSS security requirements, which include storing a quarterly report on our PCI scan status. However, we don’t have a way to schedule the report within Halo, so we have to create a ticket outside of Halo reminding someone to go into Halo and pull the report. Seems this should be part of the PCI compliance process within Halo: send me a quarterly executive summary.
Completed
15Recently shipped
Need to start supporting SSO/SCIM SAML Authentication
SSO/SCIM authentication/provisioning provides a better security posture for organization to be able to central accounts with vendors when users/employees come and go. Halo, as a cyber security company, should provide support for this.
Integration with Power BI
Utilize Power BI integration to create our own dashboards and reports. https://learn.microsoft.com/en-us/power-bi/developer/
Increase Issue Report Limit to 100 Targets
Could you please increase the issue report limit from 50 to 100 targets? We typically need to report on 80-100 targets. Thank you.
Centralized Client ID / Secret Management for Integrations (Admin Only)
Customers need a way to centrally manage integration credentials (Client IDs and Client Secrets). Today, when a credential such as an Azure Client Secret is rotated, it must be manually updated in every integration where it is used. This becomes difficult when the same Azure application is used across multiple integrations, as there is currently no easy way to identify which integrations share the same Client ID. Proposed Enhancement: Add a centralized credential management section within the Company Settings page of the platform. Location: https://app.halosecurity.com/user/account/company/ This new section would allow administrators to securely store and manage Client IDs and Client Secrets used by integrations. When configuring or editing integrations, users would be able to select an existing credential from this centralized list instead of manually entering the Client ID and secret each time. Access Control: This section should only be visible within the Company Settings page. Access should be restricted to Admin users only. Client Secrets should remain masked/encrypted in the UI. Key Benefits: Simplifies credential rotation (e.g., Azure client secret rotation). Eliminates the need to manually update credentials across multiple integrations. Reduces configuration errors when secrets are rotated. Provides visibility into which credentials are being reused. Additional Suggested Capability: Provide a simple export or table view showing: Integration Name Associated Client ID This would allow administrators to quickly identify which integrations rely on a specific Azure application when credentials are rotated. Example Use Case: A customer recently rotated a secret on an Azure application used across 15 integrations. Because the platform does not show Client IDs in a centralized way or allow credential reuse, the team had to manually open and update each integration individually. A centralized credential store would allow the secret to be updated once and automatically applied to all integrations using that credential.
Add Adjustable Columns (Including Tags) to Domains Page
Enable adjustable columns on the Domains (Seeds) page to allow users to display associated tags, making it easier to correlate domains with discovery automation and asset grouping. Page / Area Affected Domains (Seeds) page https://app.halosecurity.com/user/settings/seeds/domains/ Problem Statement Users can create automation rules that apply tags to domains and their discovered assets. However, there is currently no way to see which tags are associated with which domains directly on the Domains page. This makes it difficult to: Verify automation behavior Quickly understand domain-to-tag relationships Manage discovery and scoping at scale Proposed Enhancement Add adjustable/configurable columns to the Domains page, similar to other list views in the platform, including (at minimum): Tags (multi-value column) (Optional, future) Discovery status, asset counts, last discovered date Users should be able to: Enable/disable columns Add a Tags column to view which tags are associated with each domain User Value / Impact Faster validation of discovery automation Clearer mapping between domains and asset groups Reduced manual cross-checking between domains, targets, and tags Better scalability for customers with large discovery footprints
Align Target Risk Meter Color With Severity Context
Update the Target Risk Meter color logic so that targets with only low-severity findings (e.g., Severity 3) are visually represented as low risk, with a color that reflects minor exposure rather than a misleading “perfect/fully healthy” state. Current Behavior A target with a Severity 3 vulnerability (example: TLS 1.1 enabled) may have an overall risk score of 100. Based on current thresholds: Low risk: 0–299 Medium risk: 300–599 High risk: 600+ The target is marked green on the risk meter, visually implying no meaningful risk, even though an actionable vulnerability exists. Problem The current green risk meter conflates “low risk” with “no risk.” Customers interpret a fully green meter as “nothing to address,” which reduces visibility of: Minor but actionable hygiene issues (TLS 1.1, weak ciphers, minor headers, legacy protocols). This causes confusion when: An issue list clearly shows open vulnerabilities But the target visually appears “perfect” Requested Enhancement Red - High Risk Target Orange - Medium Risk Target Yellow - Low Risk Target Green or another color - Fully Clean Target
Add Timestamp Column within Event Summary
URL: https://app.halosecurity.com/user/security/events/list Currently, you have to click into an event to figure out the timestamp of the event or hover over the date to know the time that the alert occured. We need a column available for a timestamp.
API Access to Retrieve Scanner Source IPs Used in Specific Scans
We would like to programmatically identify the exact IP addresses used by Halo’s scanning engines during each vulnerability scan. While the UI currently shows scanner IPs per scan under the “Scan Details” section, there is no API endpoint available to retrieve this information automatically. Our team uses Tines for workflow automation and has integrated Halo Security’s API to pull scan data. However, without access to the scanner IPs via API, we’re unable to automatically correlate scan activity with logs and firewall data. This feature would help streamline automation, improve security event correlation, and reduce time spent manually checking scan data in the UI.
Integration with PagerDuty
An integration with PagerDuty would be helpful to feed Halo Security alerts in case of a risk issue being detected.
Allow target filters/actions to also apply to assets
While I realize that assets don’t have all of the properties that a target has (once scanned), candidate assets do a have a lot of properties that could be used to filter. Why? We use a large collection of target filters to auto-tag targets for purposes of GRC assignments (who gets the call when a site is vulnerable). We have a lot of business knowledge encoded into these filters. But those filters don’t assist us in finding new assets that should maybe be targets. I have to look at the target filter, then manually search through the discovered asset list for new things that might need to be scanned. Much like there is a “view N targets” button when looking at the Target Filter’s “Matches” section, I wish there was a “view N assets” button to look at what assets match this filter.