Skip to content

Security Architecture

Muneris Mobile Ordering implements a comprehensive security architecture based on documented multi-layer security controls, transparent authentication mechanisms, and compliance frameworks. The security model prioritizes verifiable protections that can be audited and validated by enterprise security teams.

Multi-Layer Security Model

The mobile app implements a documented four-layer security architecture for all backend communication:

Layer 1: Property Code Authentication

384-bit Property Code System:

  • Cryptographically Secure: Random 384-bit identifier per property
  • Dual Purpose: Authentication (validate API requests) and identification (return property-specific data)
  • Access Isolation: Property code grants access only to specific property's data
  • Rate Limiting: Per-property-code rate limiting prevents abuse and DDOS attacks
  • Data Boundaries: Technical enforcement of multi-tenant data separation

Layer 2: Device-Specific Encryption

Asymmetric Bootstrap Phase:

  1. Keypair Generation: Android keystore generates unique public/private key pair per device
  2. Public Key Transmission: Device public key sent to backend during setup
  3. Email Confirmation: Backend sends confirmation email with 120-second window
  4. Symmetric Key Exchange: Backend generates device-specific symmetric key after email confirmation
  5. Secure Delivery: Symmetric key encrypted with device public key and transmitted

Ongoing Symmetric Operations:

  • Memory-Only Keys: Symmetric key never stored on device, only decrypted into memory when needed
  • Hardware Protection: Android keystore protects private key with hardware-backed security
  • Payload Encryption: All data payloads encrypted/decrypted using device-specific symmetric key
  • No Cross-Device Access: Each device operates with its own unique encryption context

Layer 3: Transport Security

HTTPS Implementation:

  • TLS Encryption: All communication over encrypted HTTPS connections
  • Certificate Validation: Active certificate validation to prevent man-in-the-middle attacks
  • Double Encryption: Data encrypted with symmetric key, then transmitted over HTTPS

Layer 4: Application Integrity

Digital Signing Protection:

  • Muneris Certificate: App digitally signed with certificate held exclusively by Muneris
  • Keystore Access Control: Android keystore grants access only to validly signed applications
  • Tamper Detection: Invalid signatures result in immediate loss of keystore access
  • Impersonation Prevention: No other application can access device encryption keys

Authentication Architecture

JWT-Based Passwordless System

Token Structure: 

{
  "sub": "user_id",
  "email": "user@company.com",
  "companyCode": "ABC",
  "companyName": "Company Name Ltd", 
  "iat": issued_at_timestamp,
  "exp": expiration_timestamp
}

Cryptographic Implementation:

  • Algorithm: HMAC-SHA256 for signature generation and verification
  • Token Signing: All tokens signed with application secret key to prevent tampering
  • Validation: Token signature and expiration validated on each API request
  • Company Scoping: Tokens provide access only to specific company data

Secret Key Management

Automated Secret Rotation:

  • Rotation Schedule: Application secret key rotates automatically every 14 days
  • Overlap Period: System maintains both current and previous secret keys during transition
  • Zero Downtime: Token validation continues seamlessly during rotation
  • Secure Storage: Secrets stored in Azure Key Vault with version management

Validation Process:

  1. Attempt validation with current secret key
  2. If validation fails, attempt with previous secret key
  3. If both fail, reject token as invalid
  4. Log which secret was used for successful validations

Security Benefits:

  • Limited Exposure: Compromised secrets have maximum 28-day exposure period
  • Continuous Protection: Regular rotation reduces long-term compromise risk
  • Overlap Safety: Tokens issued near rotation remain valid during transition

Rate Limiting Implementation

Regional Rate Limiting:

  • Per-User Limit: Maximum 3 login attempts per email per minute per region
  • Global Effect: Maximum 9 attempts per minute per email across all regions (3 regions × 3 attempts)
  • Reset Window: Counters reset every 60 seconds
  • Serverless Compatible: No in-memory state; data persisted to user profile storage

Effectiveness:

  • 99%+ Abuse Reduction: Prevents mass automated attempts while allowing legitimate retries
  • Minimal Impact: Limited impact on real users (typically 1-2 attempts from single region)

Data Protection Strategy

No Sensitive Data Storage

Data Minimization Approach:

  • Guest Data Protection: No guest payment information stored on device
  • Transaction Isolation: Payment details handled by separate payment provider application
  • Minimal Collection: Only necessary operational metrics logged
  • No PII Storage: No personally identifiable information retained on device
  • Receipt Cleanup: Automatic 48-hour deletion of receipt data for privacy compliance

Payment Processing Security

Separation of Concerns:

  • Separate App Architecture: Payment processing handled by dedicated payment provider application
  • Secure Inter-App Communication: Android Intent or SDK-based communication protocols
  • PCI Compliance: Payment app handles PCI requirements independently from Muneris app
  • No Card Data Access: Muneris app never handles raw payment card data
  • Amount-Only Transfer: Only transaction amounts transferred between applications

Multi-Tenant Isolation

Company Data Boundaries:

  • Technical Enforcement: Users can only access their company's properties and settings
  • API Scoping: All API operations automatically scoped to authenticated company
  • Property Boundaries: Device binding restricts access to single assigned property
  • Multi-User Support: Multiple admin users per company with equal permissions within company scope

Threat Model and Mitigations

Device Compromise Protection

Threat: Restaurant device theft or compromise

Documented Mitigations:

  • Device Binding: Devices bound to specific property, useless outside restaurant context
  • Local Encryption: All local data encrypted with device-specific keys
  • Remote Deactivation: Property code regeneration revokes access for all existing devices
  • No Sensitive Storage: No payment data or customer information stored locally

Network Attack Prevention

Threat: Network-based attacks on restaurant WiFi or internet connection

Documented Mitigations:

  • Transport Encryption: All communication protected with HTTPS/TLS encryption
  • Certificate Validation: Mobile app validates specific server certificates
  • API Authentication: All API requests require valid authentication tokens
  • Regional Failover: Network issues in one region don't affect other regions

Data Breach Prevention

Threat: Unauthorized access to customer or business data

Documented Mitigations:

  • Multi-Tenant Isolation: Technical enforcement of company data boundaries
  • Access Controls: Role-based access with complete audit trails
  • Encryption at Rest: All sensitive data encrypted in Azure Table Storage

Security Monitoring

Audit and Logging

Comprehensive Tracking:

  • Authentication Events: Complete logging of all authentication attempts and outcomes
  • API Access Logs: Full audit trail of API requests and responses with property code context
  • Configuration Changes: Logging of all property and company configuration modifications
  • Error Tracking: Comprehensive error logging for security event identification

Incident Response Capabilities

Response Mechanisms:

  • Token Revocation: Ability to invalidate JWT tokens for compromised accounts
  • Device Deactivation: Property code regeneration to revoke device access
  • Account Suspension: Ability to suspend user access pending investigation
  • Audit Trail Access: Complete access logs for incident investigation and forensics

Security Enhancement Approach

Transparency-Based Security

Open Architecture Philosophy:

  • Complete Documentation: Full disclosure of security architecture and implementation
  • Verifiable Claims: All security claims backed by documented implementation details
  • Audit-Friendly Design: Security architecture designed for thorough third-party evaluation
  • Compliance Transparency: Open documentation of compliance framework implementation

Continuous Assessment

Ongoing Security Review:

  • Regular Documentation Updates: Continuous documentation of security measures and changes
  • Compliance Monitoring: Ongoing compliance with payment security and regional privacy requirements
  • Threat Model Updates: Regular review and update of documented threat mitigations
  • Control Validation: Periodic verification of documented security control effectiveness

This security architecture demonstrates Muneris's comprehensive approach to enterprise security through documented, verifiable controls and transparent compliance implementation.