Rust IoT Gateway Hardening Case Study: From Plaintext Ingest to Verified TLS

Why this case matters

This is the clearest way to understand what Combotto sells.

The system in scope was a Rust-based IoT gateway running on Raspberry Pi. The commercial question was not “can you review the whole platform?” It was narrower and more useful:

Can one gateway path be audited fast enough to expose the real transport, auth, and guardrail gaps, then checked again after hardening so leadership and engineering can see whether posture actually changed?

That is exactly what happened here: first the path was reviewed before hardening, then it was checked again after the changes were in place.

The audit exposed concrete risk, not vague concern

The before-hardening audit produced a decision-ready picture in one pass. The report came back with:

• 4 total findings
• 3 high-severity findings
• 1 medium-severity finding
• a red posture across Identity & Cryptography, Access Control, and Data Protection

The four findings were specific:

• gateway_config_guardrails.auth_enforcement_disabled
• gateway_config_guardrails.unsafe_defaults_not_observable
• ingest_auth.unauthenticated_ingest_allowed
• ingest_auth.insecure_transport

This matters commercially because it turned a gateway hardening discussion into a scoped backlog with owners, verification logic, and a clear reason to run a focused sprint.

What the hardening sprint actually changed

The sprint was not framed as “improve security in general.” It was framed around the exact failure modes the audit exposed.

The runtime verification matters as much as the configuration change:

• unauthenticated POST /v1/ingest returned 401
• authenticated POST /v1/ingest returned 202
• the gateway stayed healthy after the hardening work

That is the difference between “we think it is fixed” and “the same path behaved differently after hardening.”

The after-hardening check proved the fixes held on the same slice

The after-hardening check did not widen scope. It rechecked the same gateway-centered path after the sprint work.

The result:

• audit status PASS
• overall posture Green
• overall risk score 0
• 0 findings
• 0 backlog items required

This is where the Combotto offer becomes easier to buy:

• the Audit made the risk easy to understand
• the Sprint fixed the highest-impact issues first
• the after-hardening check created evidence strong enough to support a lighter Retainer cadence instead of a fresh investigation

Delta reports are what turn a one-off hardening win into a retainer surface

The flagship proof is not just the green follow-up review. It is the ability to compare the before and after state without changing the story shape.

That is what the delta report provides:

• it shows which controls improved
• it confirms there were no regressions
• it gives the next release or monthly review a hardened reference point to compare against

Why this is useful to buyers

Buyers usually do not need a generic promise that an IoT consultant can help. They need to know what happens after they expose one risky path.

This case study shows that the output is:

• a leadership-readable posture call
• evidence-backed findings tied to the live path
• a sprint-ready backlog
• an after-hardening check that proves the change
• an ongoing-review reference point that supports future release or monthly review

That is the full Audit -> Sprint -> Retainer path in practice.

Best-fit situations for a similar engagement

This kind of audit-first hardening work is a strong fit when:

• a customer or procurement review is closing in
• the gateway, broker, or ingest path is moving from prototype assumptions into production pressure
• the team needs proof on auth, TLS, or reliability posture without auditing the whole estate first
• leadership needs a decision-ready picture before approving a broader hardening spend