Frequently Asked Questions
Common questions about the Helios platform — deployment, architecture, data ingestion and the five packagings. Can’t find your question? Contact us.
Common questions about the Helios platform — deployment, architecture, data ingestion and the five packagings. Can’t find your question? Contact us.
Helios is a model-driven platform that unifies governance, risk, security and identity data into one connected, auditable graph. It replaces spreadsheets and disconnected registers with a single governed model of your systems, information, risks, controls and people — running entirely in your own environment.
Five configurable packagings on one platform: Archon (governance, risk & compliance), Aegis (personnel security and security clearances), Citadel (total defence, preparedness and continuity), Atlas (OT identity governance) and Curator (asset & CMDB governance). One graph, one access model, one audit trail — start with one, add others without integration projects.
Public authorities, regulated industries and organizations with preparedness or security-classification (säkerhetsskydd) requirements — anywhere data sovereignty is a requirement rather than a preference. Helisoft delivers through established integration partners for local implementation, support and framework-agreement procurement.
On-premise. Helios is built on modern, container-based (cloud-native) technology but runs in your own controlled environment, with no cloud dependency for its core. Your governance data stays available and sovereign — through normal operations and through crisis.
Yes. Helios is container-based and runs in the environment you control, whether that is your own data center, your own cloud or a hybrid. The point is that the platform and its data stay under your control.
Instead of storing systems, people, risks, controls and assets in separate registers, Helios stores them as connected objects in a graph database: relationships are data. That is why a single control can verify ISO 27001, NIS2 and GDPR at once, and why a system’s criticality can be derived from the classification of the information it handles rather than entered by hand.
Through satellites — lightweight connectors deployed close to your source systems (HR, directories, CMDB, endpoint tools, OT environments). Satellites support event-driven collection, normalize data during transport and map it into your information model. Objects can have multiple sources.
Yes. The same satellite pipeline that collects data can carry approved changes back out — provisioning, remediation and lifecycle actions such as disabling an account when its authoritative source is removed — fully audited.
Yes — this is a Helisoft specialty. Because Helios runs entirely on-premise, the platform can be deployed inside segmented or security-classified environments, and satellites support one-way delivery across data diodes (unidirectional security gateways). Transfers stay strictly one-way: acknowledgements are handled either file-based, via a file satellite, or as manual sign-off — the pattern respects the security model instead of working around it. Organizations that run their IGA in the cloud but still rely on manual routines in OT and other sensitive networks can extend governed identity and access into those networks — automated, current and audited, precisely where identity mistakes cost the most.
Yes. Helios is model-agnostic: your organization defines and evolves its own information models — object types, attributes, restrictions and relationships — in production, without vendor development. The model drives the API, data ingestion, forms and visualization.
Taxonomies — such as information-classification levels, organizational structures, asset categories and control frameworks — are managed as governed structures in the information model. Objects reference taxonomy values rather than free text, which keeps classification consistent across every source, enables derivation (for example a system’s criticality from the classification of the information it handles) and makes reclassification a controlled, audited change instead of a find-and-replace exercise.
Yes. Helios has a built-in integration with Microsoft Entra ID: accounts, groups and permissions are collected and kept current automatically, and approved changes can be written back. Hybrid environments with on-premises Active Directory and Entra ID are supported.
Yes, SCIM 2.0 is fully supported for lifecycle management: automatic provisioning, updates and deprovisioning of users and groups. Any identity data in Helios can be exposed through the SCIM API, which also makes HR systems that use SCIM straightforward to connect as authoritative sources.
Helios authenticates through OIDC federation with your identity provider; there are no local logins. MFA, Conditional Access and similar policies are enforced by your IdP and therefore apply automatically to Helios as well.
Yes. When a person is added, changed or removed in HR, the change propagates through Helios and drives account lifecycle in connected systems. HR systems that use SCIM connect through the standard API; others connect through file or REST satellites.
No — it complements it. Helios extends governed identity and access into the places central IGA can’t reach (OT zones, segmented networks, physical sites) and acts as a policy information point that serves quality-assured attributes to your access control. Your existing IGA investment keeps working.
Helios is not another identity provider, PAM or access engine competing for the same job. It is the governed information layer beneath them: one connected, validated model of identities, accounts, systems, classifications and relationships that the rest of your stack can act on. Your identity provider still authenticates, your PAM still protects privileged access, your policy engine still decides. Helios keeps the data underneath those decisions accurate, current and traceable to its source.
No. Helios federates through OIDC against your identity provider, with no local logins, and inherits MFA and Conditional Access from it. Rather than replace the IdP, Helios governs the identity and attribute data around it, syncs roles into the realm, and can provision approved changes such as disabling and re-enabling accounts back to Active Directory and Entra ID.
Internally, Helios uses Open Policy Agent with Rego as its own engine for attribute-based access to the platform. Its more useful role in your authorization architecture is supplying the data a decision needs: an external policy engine can query the Dynamic API for identity attributes, security clearances, information classifications and organizational relationships. Virtual objects return everything for one decision in a single call, instead of stitching data together from several systems.
Helios is not a PAM tool. It does not vault credentials or broker privileged sessions. It complements PAM by governing the identity and account data privileged access rests on: who an account belongs to, whether it still has an authoritative source, and how it maps to your organization. That governed picture feeds cleaner decisions in the tools that do the vaulting and brokering.
Yes, in both directions. A change in governed identity or attribute data does not have to wait for the next token refresh to take effect. When something material changes, such as a session being revoked or a token claim changing, Helios can share that signal with the enforcement points that consume it, and it can act on signals it receives from other systems. Access is re-evaluated in near real time. This was demonstrated in a live multi-vendor Shared Signals interop at Gartner IAM London.
A governance or access decision is only as good as the attribute behind it. Helios enforces attribute quality where data enters: values are validated against the model’s rules and predefined types, changes to sensitive attributes can be routed through approval before they take effect, and every value is reconciled against its authoritative source and stays traceable to the system it came from. Because the same governed attributes are served through one API, every consumer works from a single trustworthy source instead of its own partial copy.
Per system, in a four-step flow: the review is initiated, every account holder attests their own access, the system owner decides keep or revoke per line, and the review is closed with a signed decision. Everyone with access to the system is included automatically through the graph.
Every revoke decision automatically creates a follow-up action assigned to the right owner. The review does not stop at documentation: it drives the actual removal of access, with full traceability from decision to completed change.
Yes. Helios writes approved changes to both Active Directory and Entra ID, including creating, updating and disabling accounts and managing group membership. Systems without a dedicated connector are reached through generic protocol satellites such as REST, SCIM, LDAP and PowerShell.
Read and write are separated. Helios can observe the entire directory for visibility, but write only within an explicitly designated part of it. The boundary is enforced both in the directory’s own delegation and in the platform, and every write attempt outside it is refused and logged.
Yes. Service accounts and machine identities are flagged as such in the model and can be connected to owners and certificate records, so they are governed with the same visibility and follow-up as human identities.
Yes. Helios continuously surfaces findings such as dormant accounts, accounts without owners, accounts without a connected identity, privileged accounts without MFA and passwords that never expire. Each finding is a traceable item with an action in the same system, not a report in a drawer.
Attribute-based. A policy engine decides who may see or change what based on role, group, organizational unit or any other attribute, down to individual modules and information domains. Roles are supported as a convenient way to group policies. Every action and every denied attempt is logged.
Yes. Data at rest is protected through the database’s encryption support, and all transmissions are protected with TLS 1.2 or later.
Yes. Every action in Helios, including denied attempts, is recorded in the audit log with who, what and when. Logs can be forwarded to your SIEM, and personal data in logs can be masked.
Yes. All log entries can be forwarded to your SIEM for correlation, alerting and investigation. Log data can also be masked before forwarding, so no sensitive information is disclosed outside the platform.
Session handling follows your identity provider: sign-in, session length and re-authentication policies are governed there, and additional limits such as inactivity timeouts can be configured to match your security requirements.
No. Helios runs in the environment you control, and the platform requires no connection to Helisoft or any cloud service to operate. Your data stays where you run the platform, through normal operations and through crisis.
Yes. Helios is container-based, so separate test and production environments are straightforward to run side by side, each with its own data and configuration.
Because Helios runs in your environment, backups follow your own operational routines and policies. What needs protecting is well defined: the database, the configuration and the platform containers. Your integration partner can help set the routine up.
Requirements, risks, controls, deviations and actions are modeled in the same graph as your systems and information. Controls map to requirements across several regulations simultaneously, evidence is reused, and compliance status is visible in real time instead of after the audit.
Yes. The Aegis packaging is built for organizations under the Swedish Protective Security Act: security clearance lifecycle, full traceability, documented interviews and reminders for renewals. Delivery can also be performed by security-cleared personnel when required.
Continuous vetting is driven by time-based and event-based triggers: they start processes, update information and send reminders, so a clearance is followed up throughout the employment and not only when it is first granted.
Yes. Time-based and event-based triggers start the processes, update the information and send reminders, so records checks and recurring reviews run on schedule without manual tracking.
Interviews and their outcomes are documented with full traceability, and the history is organized per person. Interview question sets are managed the same way as control questions elsewhere in the platform: one reusable pattern that keeps your question banks versioned and consistent.
Retention is automated: data is purged based on time and attributes, and audit logs support masking of personal data. Retention rules can be enforced without losing traceability.
Yes, that is much of the point. Registers that live in spreadsheets today, such as information assets, systems and record types, become connected objects in one governed model with access control, audit trail and consistent processes.
Yes. Processes, information, systems, suppliers and requirements are connected objects in the same graph, so the relationships are data you can follow and query, not documentation kept in separate registers.
Ownership is a relationship in the graph: every information object can have an owner, and the graph shows who is responsible for what. Objects without owners can be flagged automatically.
Yes. The record of processing activities is modeled as objects in the graph, connected to the systems, processes and information they concern. The record stays current as the surrounding information changes, instead of being a separate document that drifts.
Classification is a governed taxonomy in the model: information objects reference classification levels instead of free text, criticality can be derived from the classification of the information a system handles, and self-assessments can be run as processes.
Yes. The built-in query engine lets the business ask questions directly, for example who has access to spaces that require clearance. An AI capability is also on the way: customers will be able to connect the LLM of their choice to Helios through an MCP interface, so that your own AI assistant can query Helios on your behalf.
Yes. The Helios interface is available in Swedish, documentation is available in Swedish or English, and delivery and support in Swedish are provided through our integration partners.
Releases come quarterly. Because Helios runs in your environment, you decide when an upgrade is applied, and your integration partner can handle it as part of the service.
Support is tailored to the agreement and your needs. Our integration partners can deliver first and second line support on the full solution if you prefer a single point of contact.
Yes, when the customer requires it: delivery is then performed by security-cleared personnel in accordance with the Swedish Protective Security Act.
Governance, risk and security information in one connected graph, running in your own environment.
Contact information