Markena

Trust & security

Markena is operated by S H H P M services co LLC, registered in Dubai, United Arab Emirates. Everything below describes what the running product does today. Where a claim is checkable from outside — response headers, TLS configuration, the read-only scopes we request from Google and Meta — we would rather you checked it than took our word.

Accounts and access

  • Two-factor authentication on every account, owner and customer, using any standard authenticator app, with single-use backup codes. It is available on every plan, including the trial — security is not a feature we sell back to you at a higher tier.
  • Password hashing with salted scrypt. We cannot read your password, we cannot recover it for you, and no member of our team will ever ask you for it. A request that claims otherwise did not come from us.
  • Hardened sign-in. Rate limiting is applied per account as well as per network, so a distributed guessing attack spread across many addresses is blocked as quickly as a single-source one.
  • Separated sessions. Staff and customer sessions are distinct, live only in browser sessionStorage , and are scoped to separate origins — markena.co.uk for the site and staff area, app.markena.co.uk for the command centre. The browser's same-origin rule enforces that boundary, rather than a check of ours that could be wrong.

Data at rest and in transit

  • Encrypted secrets. Every connected-account token, third-party API key and stored credential is encrypted with AES-256-GCM, under a key held separately from our session-signing key. That covers both your connected accounts and the platform's own credentials — mail, storage and provider keys alike.
  • Write-only by design. No stored secret is ever returned to a browser. Once saved, an API key can be replaced but never read back — not by you, not by our own staff accounts, and not through any API response, which report only whether a credential is present.
  • Independent keys. Session signing and data encryption use different keys, so compromising one does not compromise the other.
  • TLS everywhere, with HSTS on every response served over HTTPS.

How the product behaves

  • Server-authoritative billing. Plans, Credits and balances are owned by the server and can never be forged from the browser.
  • Read-only marketing connectors. Google Ads, Meta Ads, GA4, Business Profile and Search Console are used to read your measured data. Nothing is launched or changed without your explicit approval.
  • Human-in-the-loop publishing. The AI drafts; a person on your team approves before anything is sent or scheduled.
  • Honest numbers. Forecasts, competitor figures and readiness scores are always labelled as estimates or targets until a real account is connected.
  • Isolated conversations. Every website-chat read and write is keyed by both customer and visitor, so no visitor and no other customer can reach another visitor's thread.

Platform hardening

  • SSRF protection. Website scanning and outbound CRM webhooks cannot be pointed at private or internal network addresses, and downloads are size-bounded.
  • Strict response headers — content-security policy, frame denial, MIME-sniffing protection and a restrictive permissions policy.
  • Upload validation. Images are checked by file signature, restricted to PNG, JPEG, WebP and GIF, capped at 5 MB, and deleted from disk when removed.
  • Structured logging with request identifiers, so an incident can be reconstructed precisely.

Abuse prevention

Signup and login are protected by device, network and account-history signals. Scores feed a review queue rather than an automatic ban, and a matching IP address alone never blocks an account — offices, universities and mobile networks share addresses, and treating that as guilt would be wrong.

What we do not claim

A trust page that only lists strengths is not a trust page. So, plainly:

  • We hold no third-party certification yet. We are not SOC 2 or ISO 27001 certified. The controls described here are real and in the product, but they have not been audited by an external assessor, and we will not imply otherwise to win a procurement review.
  • We rely on sub-processors. Model providers, hosting, email delivery and payments are operated by other companies, and your data reaches them in the course of running the service. Every one of them is named on the Sub-processors page, and that page is the authoritative list.
  • Content you approve leaves our control. Once you publish a post or send a campaign, it lives on the platform you sent it to under that platform's terms. Nothing we do here reaches it after that point.

Reporting a vulnerability

Please report security issues to security@markena.co.uk before disclosing them publicly, and give us a reasonable period to fix them. We do not pursue researchers who act in good faith, stay within scope, and do not access, modify or destroy other people's data.

In scope: the Markena web application, the marketing site, the public API and our official chat widget. Out of scope: denial-of-service testing, social engineering of our staff or customers, physical attacks, and reports generated by an automated scanner with no demonstrated impact. If you are unsure whether something is in scope, ask first — we would rather answer the question than receive the report.

Related

Privacy Policy · Sub-processors · Security documentation

We review this page when providers, retention periods or verified certifications change.