Last Updated: 2026-02-13
Introduction
A Product is a complete and coherent solution that delivers measurable value to customers by addressing a specific need through Outpost24’s technology.
It includes not only the software functionality, but also the user experience, supporting services, and operational model (whether SaaS or on-premise) that together ensure consistent, reliable delivery of that value.
Within Outpost24, products may be offered in two primary deployment models:
-
SaaS (Software as a Service): The product is hosted, maintained, and operated by Outpost24 in the cloud, providing customers with continuous updates, scalability, and minimal operational overhead.
-
On-Premise (Self-Hosted / HIAB): The same core product capabilities are deployed within the customer’s own environment, giving them greater control over infrastructure, data, and update cadence.
Regardless of deployment type, each product is characterized by:
-
A clear value proposition and defined customer segment.
-
A maintained set of features and integrations aligned with its roadmap.
-
Lifecycle management, including release, support, and deprecation processes.
-
Assigned ownership across Product Management, Engineering, and Support functions to ensure accountability and continuity.
A product, therefore, is not just a set of technical features or code, it is the end-to-end offering that customers adopt, use, and trust to achieve their security and business objectives.
Enforcement
This policy aims to promote consistency, transparency, and shared responsibility in how we communicate and manage product support scope, version lifecycle, and customer expectations.
All team members involved in customer support, product management, engineering, and related functions are encouraged to follow the principles and processes described in this policy to ensure alignment across the organization and a unified customer experience.
Adherence to this policy helps maintain clarity and efficiency in our customer interactions. If deviations or improvement opportunities are identified, they should be addressed collaboratively between teams and management to ensure the policy remains accurate, effective, and relevant over time.
Distribution and Due Care
This policy must be communicated to all relevant Outpost24 teams, including Product Management, Engineering, and Support and ASM O24 customers.
Managers are responsible for ensuring that all team members have read, understood, and acknowledged this policy, and that the defined product support boundaries are consistently applied when interacting with customers or partners.
Questions, clarification needs, or potential exceptions should be directed to the Product Operations or the Product Management organization to ensure alignment and consistency across all customer communications.
Purpose and Scope
The purpose of this policy is to define the framework for managing product version support across all Outpost24 SaaS & On-premises products and their corresponding Application Programming Interfaces (APIs).
This policy establishes clear guidelines on:
-
Version lifecycle and duration of support.
-
Scope and level of support for outdated or unsupported versions.
-
Supported operating systems (OS) and database (DB) environments.
-
Communication and responsibilities for both SaaS applications and APIs.
This policy applies to all Outpost24 product, engineering, and support teams involved in product lifecycle management and customer communication.
Policy Scope
This policy applies to:
-
All SaaS-based products developed, maintained, and operated by Outpost24.
-
All On-premises products developed, maintained, and operated by Outpost24.
-
All published and customer-facing APIs as part of those SaaS or On-premises products or as individual integrations.
It covers:
-
Product and API version lifecycles.
-
Deployment frequency and maintenance cadence.
-
Supported environments (browsers, OS, API clients).
-
Customer and partner responsibilities.
-
Communication and change management.
Policy Principles
-
Always on the latest version
All SaaS customers and API users operate on the latest available version. Updates and improvements are deployed automatically by Outpost24. -
Continuous deployment and improvement
The SaaS environments follow a continuous deployment model, ensuring regular delivery of new features, bug fixes, and security updates (usually, monthly). -
Backward compatibility and stability for APIs
Outpost24 maintains backward compatibility within each major API version. Deprecations will be announced at least 90 days before the major version release that decommissions them. -
Transparent support limits
Outpost24 provides support exclusively for current and active solution software and API versions. Deprecated API endpoints or features outside of the announced support window will not receive updates or bug fixes. -
Shared responsibility model
Outpost24 maintains infrastructure availability (for SAAS), version stability, and security. Customers and partners are responsible for using supported browsers, SDKs, or client integrations and for keeping their own implementations as well as On-premises deployments up to date.
Under this policy, the customer will receive support for a product if the following criteria are met:
-
Customers must have a valid license or subscription agreement to use the product.
-
Customers must keep up to date with payments in accordance with the terms of their subscription.
-
The product in question has not entered End-of-Support.
-
Customers must follow product requirements, including requisite hardware for on-premises deployments.
Product and API Lifecycle
Outpost24 delivers its products through two main delivery models: SaaS and On-premises. While SaaS customers automatically receive the latest version, on-premises customers are responsible for keeping their installations up to date to remain within the supported lifecycle.
The same principles of stability, transparency, and version governance apply across both product models and their corresponding APIs.
SaaS Products
-
All SaaS users are automatically updated to the latest available version.
-
Deployment frequency: typically, every 1–3 months, depending on feature readiness and quality assurance. Deployment schedules may be paused during major holiday periods to minimize operational risk.
-
Downtime: SaaS deployments are designed for zero or minimal downtime; any expected impact beyond that is communicated in advance. Occasionally, a larger update may require an extended maintenance window. Although we generally provide advance notice of these activities -usually up to 3 months- there may be brief periods of temporary downtime or reduced functionality lasting a few hours during the deployment, especially when it involves data migration. These shorter interruptions cannot always be announced with the same level of advance notice. Outpost24 reserves the right to plan maintenance events with lesser notice in case of critical issues and patches.
-
Release documentation: all updates include public release notes in the Knowledge Base or within the product itself, detailing new functionality, fixes, and potential deprecations.
On-Premise Products
-
On-premise products include both; deployments separate from our SAAS solutions (e.g. HIAB) and deployments as components coupled to our SAAS solutions (e.g. Agents & RC-scanner).
-
On-premise product versions are given general support for 30 days after they are superseded.
-
Receiving the latest updates for detection and vulnerability definitions may sometimes require software updates earlier than those 30 days.
-
-
On-premise product versions will be able to update to the latest version for at least 90 days after they are superseded.
-
When on-premise major version updates require significant manual intervention, such as; adding or upgrading 3rd party dependencies; or requiring configuration changes, the customer will be given at least 90 days to apply changes.
-
If an on-premise product will be discontinued, the customer will be given at least 6 months to migrate to Outpost24s replacement product. When Outpost24 provides no replacement product the customer will be given at least 12-month notice.
-
Customers running unsupported versions assume full responsibility for operational or security risks until the system is updated.
API Lifecycle
-
APIs are classified as published (external) or non-published (internal).
-
Published APIs are documented and versioned.
-
Non-published APIs are considered internal and may change at any time without notification. They are not subject to backward compatibility guarantees.
-
-
Requests to publish or expose an internal API for external or partner use must follow the standard product feature request process, including:
-
Product Management approval.
-
Security and compliance review.
-
Documentation readiness.
-
Assignment of a supported version and owner.
-
Once approved and published, the API becomes subject to the same lifecycle, support, and deprecation rules as other customer-facing APIs.
-
-
APIs are versioned using a major.minor scheme (e.g., v1, v2.1).
-
Minor versions are backward compatible and may introduce new non-breaking functionality and deprecation notices.
-
Deprecations will be included in API documentation, release notes and as deprecation headers where applicable.
-
-
Major versions may include breaking changes.
-
Decommissioning of a feature of the API will only happen at least 90 days after it has been deprecated.
-
-
API users are responsible for updating their integrations accordingly to ensure continuity and security compliance.
Exceptions
Only security vulnerabilities may receive an exception, subject to approval by Product Management and Security leadership.
Supported Environments
Web UI Applications
-
Supported Browsers:
Any modern browser based on Chromium, Gecko, or WebKit, with updates not older than 12 months. Examples:-
Google Chrome (latest stable)
-
Microsoft Edge (latest stable)
-
Mozilla Firefox (latest stable)
-
Safari (latest stable)
-
APIs
-
Supported Clients:
Outpost24 APIs can be accessed via HTTPS using any standard client or integration framework that supports current TLS encryption protocols. -
Authentication:
Only secure authentication methods (e.g., OAuth2, API tokens) are supported. Legacy authentication methods, if deprecated, will follow the same lifecycle and notice period as API versions. -
Rate Limits and Fair Usage:
APIs are subject to rate limiting to ensure platform stability. Exceeding limits may result in throttling or temporary suspension in line with service terms.
On-Premise Applications
-
Each on-premise product will have different 3rd party dependencies that will be managed and provided by the customer. Management and updates for 3rd party components are the sole responsibility of the customer for on-premise deployments.
-
Outpost24 will only support our software when using 3rd party dependencies versions within our requirements, that have not entered end-of-life.
-
The product documentation for each on-premise product will outline detailed 3rd party requirements.
-
When Outpost24 makes changes to those requirements, outside of 3rd party support lifecycle, the customer will be given at least 90 days of notice.
Documentation and Access
Accurate, accessible, and up-to-date documentation is essential to ensure effective use and integration of Outpost24 products and APIs. This section defines the principles for documentation publication, access, and maintenance.
Product Documentation
-
Product documentation includes user guides, installation and upgrade instructions (for on-premise products), release notes, and known limitations.
-
Documentation for SaaS and on-premise products will be published in the Outpost24 Knowledge Base and updated with each new release or major change.
-
EASM currently includes documentation inside the platform itself rather than the Knowledge Base.
-
-
Customers are responsible for reviewing the release notes and documentation to stay informed of changes, new features, and deprecations.
API Documentation
-
Published APIs are included in the official knowledge base (unless otherwise noted) (pending to add here link to KB) that will contain a list of the published APIs with links to their respective online, interactive documentation portals.
-
EASM documentation resides inside the platform itself.
-
-
Internal or experimental APIs or endpoints will not be listed publicly, or clearly marked as such in any documentation, and may change without prior notice.
-
The preferred and maintained delivery format is online documentation, ensuring that customers always access the latest version.
-
For on-premise products such documentation is part of deployments to ensure accuracy of each deployed version.
-
Documentation Access and Permissions
-
API documentation is intended for customers, partners, and authorized users.
-
Access may be:
-
Public, for example open APIs or publicly accessible endpoints.
-
Restricted, requiring a valid Outpost24 login or Non-Disclosure Agreement (NDA), depending on the product’s sensitivity or exposure level.
-
-
Each product team is responsible for defining and maintaining access controls according to the product’s security classification and data exposure.
Documentation Maintenance and Review
-
Product & Engineering Management are responsible for ensuring that documentation reflects current versions, supported features, and lifecycle status.
-
Engineering teams must update API specifications as part of the release process.
-
Regular reviews will be conducted to ensure accuracy, completeness, and consistency across products and APIs.
Governance and Responsibilities
Internal Team Responsibilities
-
Product Management: is responsible for maintaining this policy, timelines defining versioning and deprecations, and ensuring internal alignment.
-
Engineering: Ensure compatibility with supported environments and defining upgrade paths. Oversees API versioning, deployment, and technical enforcement of compatibility rules.
-
Support and Customer Success: Communicate policy boundaries to customers, provide guidance on upgrade options, and report recurring out-of-support cases.
This policy is reviewed annually or whenever significant SaaS or API lifecycle changes are made.
Customer & Partner Responsibilities
-
SaaS customers must ensure their environments (e.g., browsers, networks, and integrations) remain within supported configurations.
-
On-premises customers are responsible for:
-
Ensuring they are always running a supported version of their products.
-
Upgrade support can be available through a Services agreement o Maintaining supported 3rd party dependencies in their environments.
-
-
Monitoring Outpost24 communications for release and End of Support (EoS) notices.
-
-
For API users:
-
Regularly review and adapt integrations to current API versions.
-
Avoid reliance on undocumented or deprecated endpoints.
-
Monitor API communications (e.g. headers, status codes) for deprecation notices.
-
-
Review release documentation and follow migration guidance when applicable.
-
Report issues or incidents via official support channels.
Communication and Change Management
Release Communications
All SaaS, on-premise, and API releases are documented in the Outpost24 Knowledge Base and within the product itself, including:
-
New features and functional improvements
-
Security or compliance updates
-
API versioning details and deprecations
-
Known issues and limitations
-
Deployment or upgrade notes (for on-premise products)
Release Notes will be published for every production deployment or product release. Where applicable, release summaries may also be distributed via email notifications, in-platform messages, or through customer success channels.
Advance Notice for Changes
To minimize impact and ensure customer readiness, Outpost24 will provide advance communication for any change that may affect customer operations or integrations:
-
Major or breaking API changes: minimum 90-day notice before decommissioning or behavioral changes. Applies exclusively to published APIs.
-
Feature deprecations: minimum 90-day notice, accompanied by migration or upgrade guidance when applicable.
-
Product End-of-Support with replacement: minimum 6-month notice, accompanied by migration or upgrade guidance.
-
Product End-of-support without replacement: minimum 12-month notice.