[Avg. reading time: 11 minutes]
Auditing in IoT
Auditing in IoT means recording who did what, when, from where, and to which device or data so incidents can be investigated and compliance requirements can be met.
Why Auditing Matters
IoT environments are hard to trust because devices are distributed, long-lived, and often remotely managed.
Without proper audit trails, you cannot reliably answer:
- Who accessed sensitive data
- Who changed device configuration
- Which API triggered a device action
- Whether a firmware update was authorized
- How an incident spread across systems
What to Audit
Device Activity
- Device boot and shutdown events
- Sensor status changes
- Configuration changes
- Local authentication attempts
- Connectivity loss and recovery
- Error and fault conditions
Data Access
- Who accessed sensitive data
- What data was accessed
- When it was accessed
- Whether it was viewed, exported, modified, or deleted
API Usage
- Authentication attempts
- Token usage
- Read and write operations
- Bulk exports
- Failed requests
- Rate limit violations
Firmware and Remote Control
- Firmware update start and completion
- Firmware version changes
- Update source and signature verification result
- Remote commands issued to devices
- Command success or failure
Best Practices
Use Tamper-Resistant Logging
- Store logs in append-only or write-once storage
- Restrict log deletion and modification
- Digitally sign critical audit records where needed
Standardize Time
- Sync systems with NTP
- Use UTC timestamps consistently
- Record time with enough precision for investigations
Add Correlation IDs
- Attach a correlation ID to each request or workflow
- Propagate that ID across device, broker, API, processing, and dashboard layers
- This makes incident tracing much easier
Log Enough, But Not Everything
- Capture security-relevant actions
- Avoid dumping unnecessary personal data into logs
- Mask or hash sensitive values when possible
Separate Audit Logs from Application Logs
- Application logs help debugging
- Audit logs support accountability, forensics, and compliance
- Do not mix them carelessly
Common Tools
ELK Stack
- Elastic for indexing and search
- Logstash for ingest and transformation
- Kibana for dashboards and investigation
Good for:
- Large-scale search
- Centralized log analytics
- Security investigations
Grafana
- Lightweight alternative for log aggregation and visualization
- Often simpler to operate than a full ELK stack
Good for:
- Smaller teams
- Cost-conscious environments
- Fast operational dashboards
Retention Policies
Retention should balance:
- Compliance needs
- Security investigation needs
- Storage cost
- Privacy risk
Example Retention Guidelines
| Data Type | Retention Period |
|---|---|
| Raw sensor data | 7 to 30 days |
| Aggregated metrics | 6 to 12 months |
| User consent logs | 5 to 7 years |
| Health-related regulated data | 6+ years, depending on policy and law |
Storage Strategy
Use tiered storage so data moves through stages over time:
- Hot for recent searchable data
- Warm for less frequently accessed data
- Cold for long-term retention
- Delete after policy expiry
Enforcement Mechanisms
- Object storage lifecycle policies
- Blob storage lifecycle rules
- Database TTL where supported
- Scheduled archival and purge jobs
InfluxDB and TTL
For time-series workloads, TTL-style retention is useful because raw IoT telemetry grows fast.
Typical pattern:
- Keep high-resolution raw data for a short period
- Downsample into hourly or daily aggregates
- Retain aggregates much longer
- Expire raw data automatically
This reduces:
- Storage cost
- Query load
- Compliance risk from over-retention