What's new in SecPal

SecPal is operations software for German private security services. We build in the open — every Android, API, and web release is documented here as it ships.

Android
app.secpal (app id)
API
api.secpal.dev
Web
app.secpal.dev
RoadmapGitHubRSS
SecPal – A guard's best friend

Android distribution surface and verified release paths

AndroidWeb

SecPal's public Android rollout is now easier to understand for end users and easier to integrate for operators: the public download surface is simplified, the machine-readable release paths are explicit, and the signing identity is published for verification.

What shipped

  • Simplified Android distribution surface on secpal.app/android: Play Store remains the primary call to action, while direct download and beta are now presented as explicit upcoming channels with their machine-readable manifests linked from the same public page.
  • Canonical release-track contract for Android artifacts and metadata: stable is the default public release path, beta remains the optional preview track, and the stable alias now resolves through the same canonical manifest structure as the explicit track endpoints.
  • Published app-signing fingerprint across the Android distribution surface and latest metadata, so operators can pin the intended signing identity before the direct APK delivery path goes live.
  • Versioned Android release metadata and artifact paths on apk.secpal.app remain available for automation and verification, while the deeper machine-readable endpoints are now clearly secondary to the primary end-user download flow.
Why it matters:

Android distribution is no longer just technically correct; it is now understandable for end users, predictable for deployment automation, and clearer about which public install paths are already live versus still being prepared.

Tenant-bound Android wrapper and push notifications

AndroidWebAPI

The Android wrapper no longer ships pinned to a single SecPal deployment, and operators can finally reach guards through the operating-system notification surface on both the browser PWA and managed Android devices.

What shipped

  • Public bootstrap discovery endpoint that publishes the API binding, tenant identity, and update channel for a SecPal deployment, so the Android wrapper can resolve its tenant at runtime instead of at build time — with strict URL-path validation on the bootstrap input.
  • Persisted Android runtime API binding with a tenant-safe reset flow: the same APK can serve multiple SecPal deployments, switch between them when an operator hands the device over, and reinitialize push and auth state cleanly on each rebind.
  • Browser web push delivery for the PWA with customer-owned VAPID keys, subscribe/refresh/unsubscribe lifecycle wiring, a hardened notification permission UX, and token re-registration after logout.
  • Android push delivery via FCM with customer-owned project credentials, runtime FCM initialization driven from the deployment metadata, push-token rotation and logout-aware re-registration, and graceful fallback when the Web Crypto API is unavailable for token derivation.
Why it matters:

Operators can now reach shift-aware notifications on both the PWA and managed Android devices without sharing notification credentials across customers, and the Android wrapper finally stops being a per-deployment build artifact.

Authentication hardening: discoverable passkeys and timing equalisation

AuthSecurityAPIWebAndroid

A focused security pass closes a handful of reconnaissance and abuse vectors around the public auth boundary — most visibly by enforcing discoverable passkeys everywhere and aligning timing on every public credential check.

What shipped

  • Discoverable-only passkeys: the public email-scoped passkey challenge was removed and registration now requires a resident credential, so credential probing by email is no longer a usable enumeration surface.
  • Login timing equalisation on both POST /v1/auth/login and the password-reset endpoint, so account existence can no longer be inferred from response delay.
  • MFA throttle preservation across retries: failed MFA verifications can no longer be reset by simply requesting a fresh challenge — the rate-limit bucket persists across challenge cycles.
  • Cross-tenant log isolation: failed-login audit entries now ignore client-supplied tenant hints, preventing log poisoning across tenant boundaries.
  • Onboarding link burn on failed identity proof: invitation links are invalidated after a failed identity-proof attempt and the HR review path now requires a verified email, closing two abuse vectors on the unauthenticated onboarding flow.
Why it matters:

Each fix closes a small but real reconnaissance surface. Together they make account enumeration meaningfully harder for an adversary probing the public auth boundary, and they remove a class of side-channel signal an attacker would otherwise use to map valid accounts.

Pre-contract onboarding and compliance tracking

APIWeb

The first end-to-end SecPal workforce flow is live: a new employee can be invited, complete their pre-contract dossier themselves, and HR keeps certifications and work authorizations from silently lapsing on shift.

What shipped

  • Pre-contract onboarding wizard: schema-driven, localized (DE/EN) form templates with draft autosave, inline attachment uploads into per-tenant encrypted storage, resubmission after rejection, and an explicit pre_contract → ready_for_activation → active lifecycle gate that no longer relies on implicit completion flags.
  • Residential address history: structured employee_addresses with encrypted street/postal/city fields, the five-year history window required by the Bewachungsverordnung for employee records, and OpenPLZ-backed German street and locality autocomplete in every employee form.
  • Compliance and expiring documents: encrypted non-EU work-permit numbers and firearms-license storage, structured first-aid / fire-safety / evacuation tracking, daily 30/7/0-day expiry emails, an HR compliance-alerts endpoint, and automatic blocking of customer and site assignments when a linked employee has expired or critical documents.
  • Encryption at rest for employee phone numbers and uploaded documents, with sanitized filenames and signed Content-Disposition handling.
Why it matters:

Expiring guard certifications and work authorizations must not silently lapse mid-shift, and onboarding paperwork should not be the bottleneck between a signed contract and a first deployment. SecPal turns both into a tracked operational process instead of spreadsheet busywork.

Passkeys, MFA, and an encrypted offline vault

AuthSecurityWebAndroidAPI

Phishing-resistant sign-in is now live across the whole SecPal stack — browser, PWA, and the native Android wrapper share one passkey and MFA story. At the same time, the web client stops keeping profile data in clear-text browser storage.

What shipped

  • Passkeys (WebAuthn / FIDO2) for sign-in and account self-service: register, list, and remove passkeys from settings, then sign in with a discoverable resident credential.
  • Native Android passkeys via the Credential Manager bridge with verified Digital Asset Links between app.secpal.dev and the SecPal app, so the same passkey works in the browser and inside the managed Android wrapper.
  • TOTP multi-factor authentication with QR-based enrollment, one-time recovery codes, self-service disablement, an admin reset path, and a dedicated MFA audit trail.
  • Encrypted offline vault for the web app: sensitive profile data moved out of clear-text localStorage into a vault-backed IndexedDB store with PBKDF2/AES wrapping, an explicit lock screen that survives reloads, and a hook for device-bound key wrapping on native runtimes.
  • Login hardening: timing-equalised account lookups, separate per-account and per-IP throttles, mandatory email verification, and authoritative server-side lockout signalling so the UI follows the backend instead of guessing.
Why it matters:

Passkeys remove the most common phishing vector for security operators on shift devices, and an encrypted vault means a stolen or unlocked browser session no longer hands over employee data along with the URL.

Android enterprise device-owner foundation

AndroidAPI

A single SecPal install can now act as a normal Android app or as a fully managed enterprise device, depending only on how it's enrolled. Same APK, same code, two operating modes — without forking the app or losing the consumer install path.

What shipped

  • Single-package app.secpal architecture with native Device Policy Controller: provisioning QR enrollment exchanges a short-lived bootstrap token against the API on first managed startup, persists the tenant, update channel, and release metadata, and falls back to the regular app experience on non-managed devices.
  • Dedicated-device kiosk: lock-task with an explicit secpal_allowed_packages allowlist, a native managed home screen with launchable-app tiles, automatic redirect of Settings and Developer Options back to SecPal HOME, status-bar shortcut disable, and a separate secpal_lock_task_enabled switch for non-kiosk managed deployments.
  • Samsung Knox hardware-button routing for XCover and SOS keys with short- versus long-press classification from hardware timestamps, so emergency entry points reach the WebView even while the app is backgrounded or starting up.
  • App-controlled gesture navigation as the managed default, including a guided one-touch detour into the system navigation-mode picker that re-enters lock-task automatically when the user returns.
  • Native auth bridge with Keystore-backed bearer tokens, base64 request and response proxying for JSON, multipart, and binary payloads, and connectivity-aware startup so cached sessions no longer burn the full HTTP timeout when the device is truly offline.
  • Release hardening: FLAG_SECURE on visible activities, screen-capture and Recents thumbnails blocked through managed policy, WebView debugging restricted to debug builds, certificate pinning on api.secpal.dev, R8 and resource shrinker with Capacitor-safe keep rules, and a network security config that disables cleartext traffic.
Why it matters:

Security operators can hand out provisioning QR codes for shared shift devices and trust that the device will boot directly into a locked SecPal kiosk — no separate enterprise edition, no manual MDM setup screens, and no leaked tokens in the WebView's JavaScript layer.