We never hold your passwords
Sign-in runs on Google Firebase Authentication. Passwords are verified on Google's servers — we never see them, transmit them or store them, so there is no password database in SmartSCM to steal.
Home / Security
Security your customers' auditors can read.
SmartSCM runs on Google Cloud Platform with federated identity, per-request token verification, TLS 1.3 and AES-256 encryption at rest. We complete vendor security questionnaires directly.
The short version
How your data is protected.
Every request is re-verified
Signing in doesn't hand out a permanent key. Google issues a signed pass that expires about every hour, and it travels with every request. Our servers re-check it before anything happens. Nothing is trusted just because someone logged in earlier.
Encrypted in motion and at rest
TLS 1.3 in transit with older versions switched off, and AES-256 encryption at rest on Google Cloud Platform with keys managed and rotated by Google Cloud KMS.
Documents handled without a middleman
Rate confirmations, BOLs, PODs and cargo photos move through single-purpose expiring links issued only to a verified user. They're never left at a guessable web address.
Separated by tenant, restricted by role
Each organisation's data is isolated by the framework, and role-based security decides who can see and change what — enforced on the server, not in the browser.
Recovery in about a minute
The database runs in a high-availability configuration on Google Cloud with 24/7 monitoring and near real-time backup. Recovery from disaster is guaranteed within 60 seconds.
Multi-factor authentication is available and can be switched on for your organisation during onboarding.
For your IT team
The technical detail, published up front.
Freight data is commercially sensitive and your customers' auditors know it. The full architecture note — token verification, retry policy, signed URLs, encryption and infrastructure assurance — is published on the Smart Info Technologies site.
- Identity
- Firebase Authentication; RS256-signed ID tokens with a ~1 hour TTL, verified against Google's published keys at the backend edge before any application code runs.
- Authorization
- Identity comes from the verified token. Role, organisation and tenant scope are resolved server-side per request; client-supplied context is never authoritative.
- Data protection
- TLS 1.3 only, AES-256 at rest via Google Cloud KMS with automatic key rotation. CMEK can be discussed where your policy requires key custody.
- Our controls
- SOC 2-aligned, positioned around access management, audit trails, monitoring, secure change management and data protection. Google's ISO 27001 and SOC 1/2/3 certifications cover the infrastructure layer — not an independent audit of our application, and we say so in every assessment.
Send us your questionnaire.
If your customer requires a vendor assessment, forward it and we'll complete it directly rather than pointing you at a portal.
Performance
The question an architect always asks about interpreted systems.
It is a fair one: if the application is read from a definition rather than compiled, what does that cost at runtime? The short answer is that definitions are resolved once and cached, so you are not paying resolution overhead per request. The longer answer is the one worth having, and we would rather give it than a reassuring adjective.
- Request path
- Resolved definitions — base, customer layer and role layer combined — are cached in memory. A request reads a prepared structure rather than re-interpreting metadata from scratch.
- Bulk and batch
- Large imports and scheduled recalculations are the workloads where interpreted execution actually costs something, and where a metadata cache does not help. We will talk about your specific volumes rather than quote a general number.
- Definition changes
- A change to a definition invalidates the cache across nodes. We will walk your team through the propagation behaviour and what a user sees during it.
- Mobile and offline
- The mobile client caches both definition and working data. Conflict resolution on reconnect is a design decision we make with you, not a hidden default.
- Ask us for the profile
- If you are evaluating us on load, ask for the performance profile and we will give you measured figures against a defined reference workload, alongside your own volume assumptions. We would rather be assessed on numbers than on claims.