Security & Responsible Disclosure

1. Our security posture

Security is part of how we build, not something added at the end. This section summarises the main controls. We describe them at a level that is useful to customers and to researchers, without giving an attacker a map.

Encryption

• In transit. Traffic between our apps, connected devices, servers and the website is encrypted with TLS 1.3. Older and weaker protocol versions are disabled.
• At rest. Personal data and backups are encrypted at rest using industry-standard algorithms, with encryption keys managed separately from the data they protect.
• Device-to-cloud authentication. Connect devices authenticate to the platform using unique, per-device credentials over mutually authenticated sessions. A single device credential can be revoked without affecting other devices or your account.

Access control

• Least privilege. Staff access to production systems is limited to what a role actually needs, and is reviewed regularly.
• Multi-factor authentication. MFA is required on all internal systems, including source control, cloud consoles and administrative tooling.
• Separation of environments. Production data is kept separate from development and test environments.

Building and running the service

• Secure development. Code changes are reviewed before they are merged, and our pipeline runs automated checks on every change.
• Dependency and vulnerability management. We track third-party dependencies, monitor them for known vulnerabilities, and patch on a risk-based schedule. Critical issues are prioritised.
• Logging and monitoring. Authentication, administrative and security-relevant events are logged, retained for a limited period, and alerted on, so that we can detect and investigate incidents.
• Data minimisation. We collect only the data we need, which reduces the impact of any incident.
• Incident response. We maintain a documented incident-response process, and we notify affected users and the Norwegian Data Protection Authority (Datatilsynet) where the law requires it.

No system is perfectly secure, and we do not claim otherwise. If you find a weakness, we want to hear about it, and we will treat a good-faith report with respect.

2. Reporting a vulnerability

Please report a suspected vulnerability privately to [email protected]. Do not open a public issue, post publicly, or share the details before we have had a reasonable chance to fix the problem.

A useful report includes:

• A clear description of the issue and where it is.
• The steps to reproduce it, using the minimum needed to demonstrate the problem.
• The potential impact, as far as you can tell.
• Any proof of concept, screenshots or logs, with personal data redacted.
• How you would like to be credited, and how we can contact you.

PGP. If you want to encrypt your report, ask us for our current PGP public key and its fingerprint when you first get in touch, and then verify the fingerprint you receive before you send sensitive detail. As a placeholder, our key fingerprint is published and kept in step with our /.well-known/security.txt file. Do not trust a fingerprint that you did not request from us directly. We will acknowledge your report, keep you updated on the fix, and tell you when the issue is resolved. Please give us enough time to respond before you escalate.

3. Safe harbour

We will not pursue legal action against, or ask law enforcement to act against, a security researcher who:

• Acts in good faith and in the spirit of improving security.
• Avoids privacy violations. Use only the minimum data needed to demonstrate the issue. Do not access, change, store or share anyone else's data.
• Avoids disruption. Do not degrade or interrupt the service, or affect other users' access.
• Gives us reasonable time to remediate before any public disclosure.
• Does not exploit the issue for personal gain, and does not demand payment to keep it quiet.

If you follow these rules, we consider your research authorised for the purposes of applicable computer-misuse law, and we will say so if we are asked. This safe harbour does not extend to anything listed as out of scope in section 5.

4. Coordinated disclosure

We work on a coordinated disclosure basis. Our target is to resolve a reported vulnerability within 90 days of receiving a complete report. We will keep you informed of our progress. If we need longer, we will explain why and agree a revised timeline with you.

If we have not fixed the issue within 90 days, and we have not agreed an extension with you, you may disclose it. Please give us a brief heads-up before any public write-up, and we are happy to review it with you for accuracy.

5. Out of scope

The following are out of scope for this programme:

• Denial-of-service testing, and anything that degrades or interrupts the service, including volumetric or resource-exhaustion attacks.
• Social engineering, including phishing, pretexting, or attempts to trick our staff or users.
• Physical attacks, and anything against our offices, staff or hardware in the physical world.
• Third-party services that we use but do not control. Report those to the provider, unless the issue is in how we have configured them, in which case we still want to know.
• Findings that rely only on automated scanner output with no demonstrated impact.
• Best-practice suggestions, such as a missing security header, with no exploitable impact. We still welcome the note; it is simply not treated as a vulnerability.

6. Reporting a concern about your own account

If you are a user and you are concerned about the security of your own account, for example because you think someone else has access to it, you should:

• Change your password, and change the password on the email address linked to the account.
• Review your active sessions and sign out of any device you do not recognise.
• Turn on two-factor authentication if your account supports it.
• Review your connected devices in Connect and remove any you do not recognise.
• Email [email protected], or [email protected] if you believe there is an active security incident.

If you want to delete the account entirely, see Delete Your Account.

7. Contact

Security reports: [email protected]. Privacy matters: [email protected]. Product support: [email protected].

We publish a machine-readable /.well-known/security.txt file so that researchers and automated tools can find the correct contact. See our Privacy Policy for how we handle personal data, or write to us at SAMMES AS, Øvrehusvegen 37E, 4054 Tjelta, Norway.