1. Summary for the Reviewer

Mālama deploys metering and environmental sensors that sign their own readings in hardware. The signed readings leave the facility over an outbound-only encrypted channel. There is no inbound connectivity, no remote shell, no control plane authority over any facility system, and no access to tenant data.

The three things a security reviewer usually wants to know, up front:

1. It cannot change anything. The appliance measures. In the default configuration it has no switching authority over power, no write access to any building or facility system, and no ability to modify anything it reads.
2. It cannot see tenant data. It measures electrical, thermal, hydraulic, acoustic, and air parameters. The optional utilization feed reads power and thermal counters from BMCs. It does not touch the tenant data plane, storage, or workloads.
3. It cannot be reached from outside. All connections are initiated outbound by the device. There are no listening services exposed to any network the operator does not control, and no vendor VPN into the facility.

If your policy prohibits third-party hardware on production networks, note that the appliance is designed to operate on an isolated out-of-band VLAN and functions fully there.

---

2. What Gets Installed

Environmental nodes are typically outside the building envelope and off the corporate network entirely. In most deployments they are the least contentious part of the install.

---

3. Network Architecture

3.1 Connectivity model

[ MRAA-01 / MGM ]  ──outbound mTLS/443──▶  [ Mālama Cloud ]
[ Env nodes ] ──LoRaWAN──▶ [ Gateway ] ──outbound mTLS/443──▶  [ Mālama Cloud ]

No inbound. No vendor-initiated sessions. No VPN tunnel into the facility.

3.2 Required egress

That is the complete list. Egress can be restricted to a destination allowlist. The device functions normally behind an explicit proxy.

3.3 What is not required

• No inbound firewall rules of any kind.
• No public IP address on any device.
• No site-to-site VPN, no vendor jump host, no remote desktop or shell.
• No access to Active Directory, identity systems, or any operator credential store.
• No DNS beyond resolving the ingest and update endpoints.

3.4 Recommended placement

Out-of-band management VLAN, isolated from both the tenant data plane and the corporate network, with egress restricted to the destination allowlist above. This is the configuration Mālama recommends and the one used in reference deployments.

---

4. Data: What Leaves the Facility

4.1 What is transmitted

4.2 What is never transmitted

• Tenant or customer data of any kind.
• Network traffic, packet contents, or flow records.
• Storage contents, memory contents, or process information.
• Credentials, keys, or configuration from any operator system.
• Video, still imagery, or conversational audio. See section 4.4 on the acoustic sensors.

4.3 The load-profile question

Per-rack power data is commercially sensitive. It can reveal utilization patterns, customer concentration, capacity headroom, and, at fine granularity, the shape of individual workloads. Treat it as confidential business information, not as environmental telemetry.

Controls available:

• Aggregation before egress. The gateway can aggregate to rack-group or hall level before transmission, at the cost of per-tenant attribution. Attestation properties are preserved because signing happens per reading, before aggregation, and the aggregate carries the constituent proofs.
• Temporal coarsening. Egress at 15-minute or hourly intervals rather than per-second, with full-resolution data retained on-device only.
• Contractual. Data ownership sits with the operator. Mālama's standard terms grant a processing license, not ownership, and prohibit resale or use in aggregate market products without written consent. Confirm this survives into your executed agreement rather than relying on this document.
• On-premise deployment. The pipeline can run inside the operator's own environment, with only the Merkle root leaving the facility. This preserves independent verifiability while keeping every underlying reading in-house. This is the strongest privacy configuration and is the one to ask for if load profile is a blocker.

4.4 On the acoustic sensors specifically

Security teams reasonably object to microphones. The acoustic nodes are sound level meters, not recording devices.

• They compute A-weighted and C-weighted sound pressure level, one-third octave band levels, and statistical percentiles.
• Only these computed values are transmitted. Raw audio is not stored beyond the analysis buffer and is not transmitted.
• Optional short audio clips for event classification are off by default. If enabled for a specific investigation, clips are retained locally, access-logged, and require explicit operator opt-in per deployment.
• Nodes are positioned at property boundary and equipment locations, not at occupied interior spaces.

If your policy prohibits any microphone on site, the acoustic package can be excluded without affecting the other domains.

---

5. Credentials and Access Requested

The Redfish and IPMI request is the one most likely to fail a security review, and it should be treated as optional in the first phase. A dedicated service account, read-only, scoped to the in-scope BMCs, rotatable by the operator at will, no privilege escalation path. Per-rack measurement works without it. Deploy the pilot without it, then decide.

---

6. Device Security

6.1 Compromise analysis

Worth stating plainly what an attacker gains at each level.

• Network compromise. An attacker on the management VLAN can observe TLS-encrypted traffic and can drop or delay it. They cannot alter a reading, because alteration invalidates a signature only the secure element can produce. Dropped readings appear as gaps in the monotonic counter and are visible in the record rather than silent.
• Appliance compromise. An attacker with code execution on the appliance can report false readings going forward. They cannot extract the signing key, cannot alter previously anchored readings, and cannot pivot to any other system, because the appliance holds no credentials to anything except its own upload endpoint. Cross-validation against the MGM feed meter and the utility revenue meter is designed to surface exactly this case.
• Mālama compromise. An attacker inside Mālama Cloud can degrade availability and can serve incorrect aggregates from the web interface. They cannot forge signed readings, and any tampering with historical data is detectable by anyone re-verifying against the on-chain roots. This is the specific reason the anchoring exists: it removes Mālama from the trust path.
• Supply chain compromise. This is the residual risk that the architecture does not eliminate. A device compromised before it reaches the operator would sign false readings with a legitimate key. Mitigations are procedural: manufacturing attestation, tamper-evident shipping, commissioning verification against a known reference load, and ongoing energy-balance reconciliation. A reviewer should weigh this honestly rather than accept the cryptography as a complete answer.

---

7. Availability and Failure Modes

For any deployment where the appliance sits in the power path, treat the availability review as a separate exercise from this document and require the hardware FMEA.

---

8. Vendor Posture: Current State

Stated plainly, because a security team will find out anyway and finding out later is worse.

A security team evaluating this should price the vendor-maturity risk accordingly and should consider requiring a penetration test as a condition of the pilot. That is a reasonable ask and we expect it.

---

9. Questions a Reviewer Should Ask

Offered in good faith, including the uncomfortable ones.

1. Can we run the pipeline entirely on-premise, with only the Merkle root leaving the facility? (Yes. Ask for it if load profile confidentiality is a concern.)
2. Can we start without Redfish or IPMI access? (Yes. Recommended for phase one.)
3. What happens to our data if Mālama ceases operations? (Require a data escrow and export provision in the contract. The on-chain anchors remain independently verifiable regardless, which is a real advantage over a pure SaaS telemetry vendor, but the underlying readings need a contractual escape hatch.)
4. Who else can see our data? (Confirm in the executed agreement, not in a datasheet.)
5. Can we get the hardware FMEA and the firmware update SBOM? (Ask. If the answer is not yes, that is informative.)
6. What is the decommissioning process for key material and stored readings? (Devices are cryptographically retired; the DID is marked revoked on-chain so post-retirement readings from that device are rejected.)
7. Will you accept a penetration test as a condition of the pilot? (Should be yes.)

---

10. Recommended Pilot Configuration

The lowest-friction path to a security approval:

1. Environmental nodes only, outside the building envelope, on a dedicated LoRaWAN gateway with cellular backhaul. No touch to any operator network. This can often be approved without a full security review.
2. MGM at the service entrance. Metering only, no operator network dependency.
3. MRAA-01 in one hall, thirty to fifty racks, monitoring configuration, out-of-band VLAN, egress allowlist, no Redfish or IPMI.
4. Ninety days. Then reassess whether utilization attribution is worth a second security conversation.

This sequence puts the least contentious hardware first and defers every request that typically triggers escalation.

---

11. Next Step

If this brief leaves questions open, ask them before scheduling anything. We would rather answer a hard security question over email than discover it in a review three weeks in. A penetration test as a condition of pilot is a reasonable requirement and we expect it.

pilots@malamalabs.com

---

Mālama Labs · pilots@malamalabs.com

This document describes intended and designed behavior for hardware that is pre-deployment as of August 2026. Statements about the appliance should be verified against the shipping hardware and firmware before being relied upon in a security decision.