Securing Midea PortaSplit in Home Assistant: Token, Key, and Home Network
The PortaSplit token and key come from the Midea cloud and never expire. Learn how to back up these values, isolate the device on your home network, and keep Home Assistant, the integration, and firmware up to date in a controlled manner.
Local control of the Midea PortaSplit relies on two device-specific values: the token and key. They authenticate the connection between Home Assistant and the device and can currently only be obtained through the Midea cloud. This results in two tasks: back up the values so that setup remains possible without the cloud, and operate the device and Home Assistant so that the values cause little damage even in the event of an incident.
The series has three parts: Part 1 describes setup through to the dashboard, this part covers security, and Part 3 covers the background behind the cloud API warnings.

Where the token and key come from
On devices using the V3 protocol, the PortaSplit accepts local commands only with a token and key. The values are not generated by the device, but by the Midea cloud; the official app retrieves them from there as well. Community integrations have reimplemented this cloud call: they sign in using the same endpoints as the app, receive the token and key, and store both locally. No cloud connection is then required for normal operation.
There is no documented local pairing mechanism that outputs the values without the cloud. In theory, they could be extracted from the app, for example through reverse engineering or runtime instrumentation; for individual users, this is labor-intensive and not a replacement for cloud retrieval. If the endpoint disappears, so does the ability to obtain them.
The project Midea AC LAN warns in its README that Midea is gradually closing the token interfaces; the integration therefore switches from cloud to cloud. Devices that have already been set up continue to work locally; new devices and reconfigurations would be affected. This is not a binding roadmap from Midea. In June 2026, it also became apparent that the supposedly closed SmartHome token API was still working; the community library’s request had simply been incomplete. The assessment of the warning and the various “V2” labels is in Part 3.
What the token and key enable
Tokens and keys do not expire. According to Midea AC LAN, client communication was originally considered adequately protected, which is why the cloud issued non-expiring tokens. This is not a vulnerability in itself; it becomes problematic when the values end up in logs or unprotected backups, reach third parties, or cannot be revoked or rotated.
Anyone who possesses the token and key and can reach the device on the network can authenticate to the PortaSplit, read status information, turn it on and off, switch operating modes, and change the target temperature. The values alone do not enable an attack from the internet; the attacker also needs a network connection to the device. Tokens and keys should therefore be treated like passwords, and the network should allow this connection only to Home Assistant whenever possible.
The community integration does not attack the air conditioner. It implements a proprietary protocol that was understood through reverse engineering. The risk arises because long-lived secrets are stored outside the intended app.
Backing up the token, key, and configuration
Backing up the token, key, and configuration is the most important one-time step: once the cloud token interfaces are closed, a backup is the only way to set it up again. Midea AC LAN stores a JSON configuration file for V3 devices after successful setup. The documented path is:
/config/.storage/midea_ac_lan/
The file uses the device ID as its file name:
<device-id>.json
This file is not an ordinary text note. It may contain the device ID, serial number, IP address, token, key, protocol information, and cloud and device parameters. Accordingly:
- Do not upload it to a public GitHub repository.
- Do not post it in forums.
- Do not share it as an unredacted screenshot.
- Do not send it by unencrypted email.
Even a private Git repository is not automatically the right storage location because secrets remain in Git history even if they are later removed from the current file. Better options include an encrypted backup, a password manager with a file attachment, an encrypted NAS backup, encrypted offline media, or an encrypted archive with the password stored separately.
To back it up through the Home Assistant terminal:
cd /config/.storage/midea_ac_lan
ls -la
View the file:
cat <device-id>.json
For copying, the file should not be transferred through a public web service. An encrypted archive that is then placed in encrypted backup storage is better:
tar -czf /config/midea-ac-lan-backup.tar.gz \
/config/.storage/midea_ac_lan
The files in .storage should not be edited manually. The developer explicitly recommends neither deleting nor directly changing the JSON file when problems occur, but renaming and backing it up before making changes.
A complete Home Assistant backup also contains these files. A separate copy is still useful because Home Assistant backups can become corrupted, a restore can overwrite the integration, the file may be needed specifically for a later reconfiguration, and a backup should never exist only on the same system.
Removing secrets from a published Git repository
If a JSON file was accidentally published on GitHub, normal deletion and a new commit are not enough. The file remains accessible in Git history. At minimum, these steps are required:
- Make the repository private immediately, if possible.
- Remove the file from the entire Git history.
- Account for GitHub caches and forks.
- Treat the token as compromised.
- Remove the device from the Midea account and reconnect it if this generates new keys.
- Set up the Home Assistant integration again.
- Change the Midea account password if credentials were also affected.
Whether pairing again actually generates a new token varies by device and cloud architecture. Do not rely on changing the account password to automatically invalidate the local device token.
Isolating the PortaSplit on the network
No port forwarding to the PortaSplit
The most common avoidable mistake would be making the local device port directly reachable from the internet. A rule like this would be dangerous:
Internet → TCP 6444 → PortaSplit
There is no good reason to make the PortaSplit directly reachable from the internet. Home Assistant is already on the local network and serves as the controlling instance. The router should not have port forwarding to the PortaSplit, should restrict or disable UPnP where possible, block incoming connections by default, and not use a DMZ rule for the device.
Dedicated IoT VLAN
The best network architecture is a separate IoT network:
VLAN 10: vertrauenswürdige Clients
VLAN 20: Server und Home Assistant
VLAN 30: IoT-Geräte
VLAN 40: Gäste
The PortaSplit is located in the IoT VLAN. Home Assistant may access the device specifically, but the PortaSplit must not be able to access PCs, NAS devices, and other internal systems without restriction. One possible firewall policy:
Home Assistant → PortaSplit: erlauben
PortaSplit → Home Assistant: etablierte Verbindungen erlauben
PortaSplit → interne Clients: blockieren
PortaSplit → NAS: blockieren
PortaSplit → Management-Netz: blockieren
Internet → PortaSplit: blockieren
During initial setup, the device needs internet access to the Midea cloud. After successful local setup, you can test whether outgoing internet access can be blocked. Do not immediately impose a permanent block. First verify whether local control still works, whether the device remains reachable after a restart, whether it survives a router restart, whether it still responds after several days, whether the MSmartHome app is still needed, and whether firmware updates are still offered. Anyone wishing to continue using cloud features and firmware updates can temporarily allow outgoing internet access and block it again afterward.
Network segmentation can prevent discovery
Automatic device discovery often relies on broadcast or multicast traffic, which is normally not routed across VLAN boundaries. Home Assistant may therefore not find the PortaSplit automatically even if a normal IP connection is allowed.
In that case, it helps to set up the PortaSplit temporarily in the same VLAN as Home Assistant, specify the device IP manually, use a suitable broadcast relay feature, or define targeted firewall rules after setup. Manual configuration is often the better option from a security perspective because it does not require allowing additional broadcast traffic between networks.
Static DHCP assignment
The PortaSplit should receive a fixed DHCP assignment in the router:
PortaSplit → 192.168.30.25
A DHCP reservation is usually preferable to a static IP configured on the device. Home Assistant finds the device reliably, firewall rules can be restricted to a fixed address, troubleshooting becomes easier, and the assignment remains stable after router or device restarts. A firewall rule can therefore be written very narrowly:
Home-Assistant-IP → 192.168.30.25:6444/TCP
The port actually required must be verified based on the integration and your own device.
Securing Home Assistant and integrations
Home Assistant as the central trust anchor
Anyone controlling the PortaSplit locally shifts some trust from the Midea cloud to Home Assistant. If Home Assistant is compromised, an attacker may control not only the air conditioner but the entire smart home.
Home Assistant should therefore be updated regularly, not exposed through unprotected port forwarding, protected with a strong, unique password, use multi-factor authentication, create encrypted backups, contain only necessary add-ons, and not allow unnecessary SSH access from the internet. For remote access, a VPN, Home Assistant Cloud, or a properly configured reverse proxy are better options than simple port forwarding on port 8123.
HACS and supply-chain risk
Midea Smart AC and Midea AC LAN are custom integrations. They run within Home Assistant and therefore have extensive access to its runtime environment. A malicious or compromised integration could theoretically read configuration data, extract secrets, establish network connections, scan devices on the local network, read states of other entities, transfer data to external systems, and affect Home Assistant availability.
This does not mean the integrations mentioned are malicious. Both projects are publicly visible, actively developed, and have a visible community. However, open source is not an automatic security guarantee. Before installation, it is worth checking at least whether the repository is actively maintained, whether there are regular releases, how many people contribute code, whether open security issues exist, whether maintainers or repository owners have changed recently, whether HACS points to the expected repository, and whether an update contains unusually large or unexplained changes.
Updates should not be installed blindly immediately after release. Especially for security-critical smart home systems, it makes sense to wait a few days and review release notes and reported issues.
Debug logs contain sensitive data
When problems arise, open-source projects often request debug logs. The documentation for Midea AC LAN shows how to enable logging for the two relevant components:
logger:
default: warn
logs:
custom_components.midea_ac_lan: debug
midealocal: debug
The logs can then be downloaded through Settings, System, and Logs. Depending on the integration and the error, such logs may contain local IP addresses, device ID, serial number, model identifier, cloud responses, account information, tokens or parts of them, network packets, as well as timestamps and usage behavior. They should therefore be reviewed and sensitive values redacted before uploading them to a public GitHub issue.
After troubleshooting is complete, debug logging should be removed again. Permanently enabled debug logging not only increases storage use; it also increases the amount of sensitive information in backups.
Cloud and firmware
Securing the cloud account
As long as the Midea cloud is used for setup or app control, the Midea account remains part of the security model. It should have a unique password that is not shared with other services, a password manager, multi-factor authentication if offered, removal of old smartphones and sessions, no shared accounts, and regular checks of which devices are registered to the account.
If the Home Assistant integration asks for a username and password during setup, check whether the credentials are used only for one-time token retrieval or stored permanently. The developers of Midea Smart AC write that devices are not linked to built-in integration accounts after setup and that the token and key can also be obtained manually through your own account using the CLI. Where possible, your own account is preferable to third-party or integrated shared accounts.
Block the cloud or not?
After successful setup, the question arises whether the PortaSplit’s internet access should be blocked completely. Arguments for blocking it include less telemetry, less reliance on external services, a smaller attack surface through the vendor cloud, the fact that the device cannot contact arbitrary external targets, and less impact from cloud-side changes.
Arguments against it include the possibility that the MSmartHome app will no longer work outside the home network, that firmware updates will no longer download, that time or cloud functions may fail, that signing in again or recovery becomes more difficult, and that some devices may respond unexpectedly after being offline for a long time.
A practical sequence: set up the device normally, test Home Assistant and the app, back up the token and configuration, block internet access, restart the device and Home Assistant, observe for several days, and if necessary temporarily allow internet access again.
Firmware updates: security gain or integration risk?
Firmware updates are a dilemma for IoT devices. They can close known vulnerabilities, improve stability, modernize security mechanisms, and bring new features. But they can also change local interfaces, break reverse-engineered integrations, invalidate tokens, disable the local API, and introduce new cloud dependencies.
For example, the PortaSplit firmware released in January 2026 introduced a new quiet mode for the outdoor unit that reduces noise by around 6 decibels. The community integrations first had to understand and implement it, as documented in a dedicated GitHub issue for the PortaSplit.
The conclusion: do not block firmware updates categorically; before an update, check whether other Home Assistant users report problems, back up the configuration and token beforehand, create a Home Assistant backup, and fully test local control after the update. Security does not mean “never update.” Outdated firmware can be more dangerous than a temporarily incompatible integration.
What Midea itself says about security
Midea promotes its SmartHome ecosystem as aligning with several security and privacy standards, including EN 303 645, UK PSTI, NIST, GDPR-compliant data processing, and the requirements of the EU Radio Equipment Directive. These are positive signals, but they do not say how each individual PortaSplit firmware version, cloud endpoint, and local API is actually implemented. Certification and marketing claims do not replace technical review of the specific device.
Likewise, it would be wrong to infer from a community integration warning that the PortaSplit is generally insecure. The issue described concerns the architecture of long-lived tokens and their use by unofficial clients.
Risk by scenario
| Scenario | Risk | Reasoning |
|---|---|---|
| Normal home network without port forwarding | manageable | An attacker must first gain access to Wi-Fi, Home Assistant, or a backup. |
| Flat home network with many insecure IoT devices | medium | A compromised IoT device can reach the PortaSplit or Home Assistant on the same network. |
| PortaSplit directly reachable from the internet | high | The device should never be exposed through port forwarding. |
| Token and key public on GitHub | high | The secrets are considered compromised; whether they can be revoked is not guaranteed. |
| Separate IoT VLAN, restrictive firewall, local control | comparatively low | Even if the device has a vulnerability, freedom of movement on the network is severely limited. |
Checklist
1. Home-Assistant-Backup anfertigen
2. Token- und Konfigurationsdaten verschlüsselt sichern
3. DHCP-Reservation für die PortaSplit einrichten
4. Keine Portweiterleitung, UPnP einschränken
5. PortaSplit in ein separates IoT-VLAN verschieben
6. Zugriff von Home Assistant zur PortaSplit erlauben
7. Zugriff der PortaSplit auf interne Netze blockieren
8. Internetzugriff testweise blockieren
9. lokale Steuerung nach Neustarts prüfen
10. Firmware- und Integrationsupdates kontrolliert durchführen
The desired communication direction:
Home Assistant
│
│ gezielt erlaubt
▼
Midea PortaSplit
│
├── kein Zugriff auf PCs
├── kein Zugriff auf NAS
├── kein Zugriff auf Management-Netz
└── Internet nur bei Bedarf
Operated this way, local control is justifiable from a security perspective: the token and key remain secret and backed up, the device is reachable only by Home Assistant, and firmware and integration updates are installed in a controlled manner.
Comments
Comments are loaded from GitHub / Giscus.