Security you can audit, not just trust.

Our security posture is built for due diligence: everything below is verifiable in the running product and in the source code you export — governed AppGen with full code ownership, with approval gates and audit trails in the platform and the source in your repository. And where we are not yet certified, we say so, in writing.

Disclose a vulnerabilityTalk to security
On-prem firstApp source exportKVKK / GDPRSigned app packages, end to endYour keys, your infrastructureEnterprise SSO & role-based accessFull audit trail
Six pillars

Every control, every decision, every receipt.

Click a pillar to expand. The headline is what your security team gets, in plain language; the detail underneath is how we do it — algorithms, key handling, and the decisions behind them.

1Runs on your infrastructure, by defaultdeploy-onprem

What your security team gets: no vendor-side data plane, no mandatory telemetry, and updates you pull — never pushed to you. Your data stays on servers you control, up to and including fully air-gapped sites. Cloud is an option, never a requirement.

  • No mandatory cloud telemetry — observability is opt-in
  • No vendor-side data plane
  • Updates arrive as signed packages — pull, never push
  • Fully air-gapped install supported — offline installer flow with manual manifest signing

For your security team:the reference deployment is PostgreSQL on your servers, portal hosting on IIS / nginx, and the identity provider issuing tokens against your own AD. The same signed application packages ship to on-prem and cloud alike. Connected instances check for signed updates on a customer-controlled schedule. Installation remains customer-triggered and reversible. Air-gapped instances import signed packages manually; Createrun never opens an inbound control channel.

2Single sign-on and access control, enforced everywhereby design

What your security team gets: standards-based enterprise single sign-on, a tenant boundary enforced on every single request, and role-based access your admins configure per tenant. Bring your own corporate directory — it federates, it doesn't get replaced.

  • Each customer's access strictly isolated — the boundary is enforced on every call, not per app
  • Role-based access with predefined administrative groups plus custom roles per tenant
  • Multiple identity providers coexist — local accounts, one or more corporate directories, federated login
  • Bring your own AD / Azure AD via OIDC federation

For your security team:the identity provider is built on OpenIddict — OAuth2 / OIDC with refresh tokens, JWT RS256 signing keys under managed rotation, and a public/.well-known/license-pubkeyendpoint plus revocation list for verifiers. The authorization store is hardened for concurrent writes with atomic, per-user persistence.

3Every app package is signed — twiceby design

What your security team gets: every application that reaches your servers carries two signatures — the developer's, proving authorship, and the Marketplace's, proving review. Both are verified at install; a tampered package fails before a single file is trusted.

  • Tampered or unsigned packages fail at install with a signature mismatch
  • Licenses bind to your specific installation — no copy-paste re-use
  • Failed upgrades roll back automatically

For your security team:signatures are ECDSA P-256 on the .NET BCL — a FIPS-aligned curve choice with no third-party crypto dependency. ("FIPS-aligned" refers to the algorithm and curve selection, not a FIPS 140 product certification — Createrun holds no such certification today.) Every package conforms to a versioned, published signed-package format, and the license itself is a JWT bound to the instance fingerprint.

4Verified installs, from download to first runsetup-crypto

What your security team gets: the installer verifies everything before anything lands on disk — package signatures, download integrity, server identity, and activation — and it runs standalone, with no runtime to pre-install on the target machine.

  • Both signatures checked before any file is written
  • Downloads verified as they stream — fail-fast on the first bad byte
  • Connections pinned to our published server keys — resistant to interception
  • Local session credentials stored encrypted, never in plaintext

For your security team:manifest verification is ECDSA P-256 on the .NET BCL (developer + store signatures); activation is JWT RS256 with live JWK refresh from/.well-known/jwks; transport uses SPKI pinning (SubjectPublicKeyInfo SHA-256) — MITM-resistant; downloads are SHA-256 streaming-verified; session state is protected with DPAPI on Windows and AES-256-GCM + PBKDF2 on Linux. The installer ships as a NativeAOT single-file CLI plus a desktop wizard, with no .NET runtime dependency.

5Secrets encrypted, scoped, and rotatedby design

What your security team gets: one encrypted store per installation for every secret — signing keys, database passwords, webhook secrets — where each service can read only the configuration it owns, and rotation is built in. Nothing sits in plaintext config files, and there is no external secret-manager to procure or operate.

  • Every secret lives and rotates in the Instance Configuration Store — encrypted, ownership-scoped, one per instance
  • Group ownership — each service reads only the configuration groups it owns
  • Signing keys refresh live on every activation
  • Encrypted configuration prevents plaintext secret leaks
  • Agent token + Git access-token rotation on the public roadmap

For your security team:the Instance Configuration Store encrypts with AES-GCM at rest, keys derived via PBKDF2-SHA256 at 600k iterations, BCL-only crypto. Identity-provider JWT signing keys, license signing keys, database passwords, and payment webhook secrets all live there; Setup pulls the latest signing key via live JWK refresh on every activation.

6Compliance — what's done, what's nothonest scope

KVKK + GDPR:supported through architectural choices — on-prem-by-default, each customer's access strictly isolated,DPA available pre-signature.

SOC 2:Type II audit is on the 2026 roadmap,not yet certified. Architectural controls (access logging, change management, secret rotation, secure SDLC) are in place; audit attestation is the next milestone.

Pen-test:Independent penetration testing scheduled for Q3 2026. Summary report available under NDA viasecurity@createrun.com.

Questions a security team should be asking?

We answer them in plain English. Architecture, threat model, deployment topology, secret management, key rotation, audit logging — pick a topic and book time directly.

security@createrun.com