Trust & security
Know the boundaries.
Verify the controls.
Assess easyIGA by the deployment you will run, the access it requires and the evidence available for that release. Website security and customer identity-system security are separate scopes.
Discuss your security requirements Compare deployment options Report a vulnerability
Self-hosted by default
easyIGA is a business-facing layer over the open source midPoint platform. The default deployment model places the stack on infrastructure controlled by your organisation. Your team must assess and operate network controls, encryption, backups, access administration, monitoring and recovery.
Support access should be explicitly authorised, scoped, logged and revoked when no longer needed. Confirm the actual technical arrangement in the deployment agreement. A self-hosted label alone does not prove that every integration, model endpoint or support channel keeps data within a particular boundary.
The EU-hosted option
An EU-hosted deployment operated by our team is available on request for organisations without suitable infrastructure. Before contracting, obtain the actual hosting locations, subprocessors, support-access arrangements, retention, backup, recovery and deletion terms. Data residency, operational access and international transfers are related but different questions.
Agree responsibilities for incident handling, patching, availability and exit in writing. A location or architecture diagram is not a substitute for the service’s contractual commitments and tested controls.
Request a concrete security evidence pack
| Area | Evidence to request |
|---|---|
| Access and authentication | IdP integration, permissions, service-account privileges, MFA boundary, emergency access and session controls. |
| Software supply chain | Release identifier, dependency inventory, vulnerability findings, build provenance and signature verification where provided. |
| Policy enforcement | Tests for unauthorised requests, privilege escalation, conflicting roles and direct administrative changes. |
| Audit evidence | Recorded events, correlation, missing-data handling, retention, access restrictions and protection against modification. |
| Operations | Backup restoration, recovery objectives, patch process, incident responsibilities and tested failure handling. |
| Exit | Export format, configuration portability, dependencies, retained licences and deletion arrangements. |
Threat-model boundaries
Least privilege, approval policy and independent records can reduce risk, but none makes a system immune to compromise. Test the permissions available to the layer and its service accounts. A compromised component may abuse the capabilities it legitimately holds. Logging in two places does not by itself establish tamper resistance or independent trust.
Governance does not replace endpoint protection, network defence, IdP hardening, PAM session controls or application security. A complete review includes those systems and the connections between them. Confirm target-system outcomes rather than assuming that an accepted request guarantees an effective change.
This website’s actual services
easyiga.com uses Cloudflare for delivery and service protection. Contact forms use Cloudflare Turnstile and a Worker; Resend delivers the resulting message to a Microsoft 365 mailbox, and the enquiry is recorded in a CRM that our team runs itself on a company server in the EU. Cloudflare, Resend and Microsoft 365 are third-party services; the CRM is not.
Optional analytics use Google Analytics 4, loaded after analytics consent. The production configuration does not activate Bing UET or AI-assisted visitor-activity processing. Brand fonts and assets are served from this website; some article photographs load from Unsplash. See the privacy notice and cookie policy for purposes and settings.
The website repository runs build and automated tests before its configured deployment job. That website pipeline is not evidence of the security controls or release process of the separate easyIGA application.
Report a concern
Security vulnerabilities in easyIGA or in this website go to security@easyiga.com under the vulnerability disclosure policy below; the same contact is published machine-readably at /.well-known/security.txt. For a security discussion that is not a vulnerability report, questionnaires, evidence packs, deployment questions, use the contact form.
Hosting wording reviewed on 24 September 2026 against the Product Owner’s decision. Website-service inventory last reviewed on 14 September 2026. For midPoint’s own advisories, use Evolveum’s security documentation.
Vulnerability disclosure policy
The website operator (“we”) wants to hear about a security vulnerability in easyIGA or in this website before anyone else does. This policy says how to report one, what we commit to in return and what we ask of you. It is written against ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), and it is the coordinated vulnerability disclosure policy that Article 13(8) of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires of a manufacturer. Version 1.0, effective 14 September 2026.
How to report
Email security@easyiga.com. The mailbox is read by more than one person, so a report does not depend on one individual being available. The contact is also published at /.well-known/security.txt in the RFC 9116 format. We read English and Slovak.
Useful in a report: which component is affected (easyIGA, midPoint, Keycloak or the website) and its version (for easyIGA, the release identifier or image digest); steps to reproduce; the impact you observed; and whether you have evidence that the vulnerability is already being exploited. If you prefer, send a non-sensitive summary first and we will confirm the address and, on request, arrange an encrypted channel before you send exploit details. We do not publish a PGP key yet; when we do, its fingerprint will appear here and in security.txt.
What we commit to
- Acknowledgement within 5 business days (Slovak business days) of receipt.
- A status update within 15 business days, and further updates as the case progresses until it is closed.
- No promised fix date. We tell you what we know, including when the answer is that a fix depends on an upstream component or is not planned.
- Credit, if you want it, in the fix record and under Acknowledgements on this page.
- We do not pay financial rewards for vulnerability reports.
Coordinated disclosure
We ask for 90 days from the date of your report before you publish details. The period is negotiable in both directions: shorter when a fix is released earlier or the vulnerability is already public; longer when a fix depends on an upstream component, on a customer’s deployment cycle or on a legal obligation, in that case we tell you why, in writing. If we fall silent, the 90 days still stand; you do not need our permission to publish after them.
What we do with a confirmed report: reproduce it, assess its severity, fix or mitigate it, record the fix in the product changelog under “Security” and communicate it to customers with the release. Where a vulnerability is being actively exploited, we also notify ENISA and the coordinating national CSIRT within the deadlines of CRA Article 14, an early warning within 24 hours of our becoming aware. That notification is our legal obligation and needs nothing from you.
Scope
In scope: the easyIGA application and its deployment artefacts as delivered by the provider identified on About us (backend, frontend, integration layer, container images and deployment scripts), and this website, easyiga.com, including its contact API.
Third-party components have their own disclosure processes and their fixes come from their maintainers. Report a vulnerability in midPoint to Evolveum (security@evolveum.com, see Evolveum’s security documentation) and a vulnerability in Keycloak to the Keycloak project (keycloak-security@googlegroups.com). If you are not sure which component is affected, send the report to us and we will route it and stay involved. Vulnerabilities in the services this website relies on, Cloudflare, Resend, Microsoft 365, Google Analytics, Unsplash, belong to those providers.
What we ask of you
- Test only what you are authorised to test. easyIGA is self-hosted by default, so an installation you find on the internet belongs to a customer: do not test it. Report what you can observe to us and we will contact the customer.
- Stop at proof. Do not read, copy, change or delete data beyond what demonstrates the vulnerability, and do not access other people’s accounts or data.
- No denial-of-service or volumetric testing, no social engineering, phishing or physical intrusion, and no automated scanning at a rate that degrades a service.
- Report promptly, keep the details confidential until the coordinated disclosure period ends, and delete any data you obtained once the report is closed.
Research carried out in good faith and within this policy is authorised by the website operator. We will not pursue legal action against you for it, and we will not ask a customer or a component vendor to do so on our behalf. This authorisation does not cover conduct outside this policy and cannot bind third parties. Reports, and any personal data in them, are handled under the privacy notice for the purpose of resolving the report and are kept as part of the product’s security record.
Acknowledgements
Researchers who reported a vulnerability under this policy and asked to be named are listed here. None yet. This policy is new.
Policy owner: the easyIGA Product Owner. Reviewed at least once a year and after every handled report. Version 1.0, 14 September 2026.