Built for the way enterprise FSM customers expect software to behave.
Altiwerkextensions run inside FSM Shell, against your tenant's own access token. Our backend handles license validation only. Your operational data never touches our servers.
Your data stays in your tenant
FSM API calls go directly from the browser to your FSM cluster (e.g. de.fsm.cloud.sap), authenticated with the access token FSM Shell already issued to the extension. We don't proxy them. We don't see them.
Licenses are signed, not stored
Each license is a JWT signed with our Ed25519 private key. The public key on our backend verifies signatures — nobody can mint a valid license without the private key, which never leaves our offline keystore.
Licenses are tenant-bound
Every license is issued against a specific FSM accountId. If a key is leaked and pasted into a different tenant, validation rejects it server-side. Sharing licenses across tenants doesn't work.
What hits our servers, and what doesn't
Two independent connections. Operational data never crosses the bottom path.
Hits Altiwerk
- ✓Your license JWT and FSM accountId (during validation)
- ✓Standard HTTP request metadata (User-Agent, IP) when calling /api/validate-license
Does NOT hit Altiwerk
- ✕Service calls, activities, business partners, equipment
- ✕User-defined object (UDO) records
- ✕SAP ERP documents
- ✕User identities or roles
- ✕Any field-level tenant data
For a full architecture diagram, see the request flow in the license documentation.
How licensing protects you
The key only validates against our backend when paired with the FSM accountId it was issued for. Anyone pasting it into a different tenant gets rejected — they never see your data, they never get past the blocking modal. Tell us and we'll revoke the key and issue a replacement; the leaked one stops working within an hour as caches expire.
The license has an absolute exp claim. After expiry, validation returns 'expired' and the extension shows a renewal message. Screens you built remain in your FSM tenant as your own data — they're stored as FSM records, not on our servers.
The extension caches the last successful validation for up to 24 hours. Brief outages are invisible to your users. After 24 hours of unreachability, the extension fails closed — you'd see a clear 'couldn't reach licensing service' message, not a silent feature loss.
Expiry is checked server-side using NTP-synced server time. Local clock changes have no effect.
We rotate the keypair, redeploy the new public key, and re-issue every active customer license. Old keys stop verifying immediately. The blast radius is contained because no operational data is ever encrypted with these keys — they only sign tiny license JWTs.
What we store
Our backing store holds one small row per issued license. That's it.
| Field | Purpose |
|---|---|
| licenseId | Stable identifier for support lookup and revocation |
| accountId | The FSM tenant the license is valid for |
| company | Customer company name (for support context) |
| entitlements | Which screen types the SKU includes |
| issuedAt / expiresAt | Timestamps for the contract window |
| status | active or revoked |
Need a security review before purchase?
We'll walk your IT/security team through the architecture and answer questions in writing. No NDAs needed for the basics.