What is host card emulation on Android?
Host card emulation lets an Android application respond to an external reader itself, in software, instead of routing the exchange to a secure element chip. It removed the hardware gatekeeper that once controlled who could deploy a card application, and moved the security problem into the operating system and the cloud.
What it replaced
Before host card emulation, presenting a card from a phone meant putting the credential in a secure element: a hardware chip, physically present in the device or in the SIM, and controlled by whoever owned that hardware.
That control was the obstacle. A bank or a transport operator wanting to deploy a card application had to negotiate access with a handset manufacturer or a mobile operator, one relationship at a time. The technology worked and the business arrangements did not scale.
How it works
Android routes the exchange to an application instead of to a chip. Google documents the mechanism under host card emulation.
An application declares which card applications it can handle, using identifiers that terminals ask for by name. When a reader asks for one of them, the operating system wakes the registered application and passes the exchange to it. The application answers, command by command, in software.
The consequence is that no hardware gatekeeper is involved. Any developer can publish an application that responds to a reader, without asking a manufacturer for permission.
Where the security went
It did not disappear, it moved, and understanding where is the difference between using this properly and building something fragile.
A secure element resists physical extraction of its keys. An application running on the main processor does not, which is why credentials handled this way are typically short lived tokens fetched from a server rather than a permanent secret sitting on the device. Steal the token and it expires. Steal the device and the token is useless without whatever unlocked it.
So the model changed from protecting a secret in hardware to limiting what a stolen secret is worth. Both work, and they fail differently.
When to use it
It is the right mechanism when you control both ends: your own application on the phone, your own readers in the field. Loyalty schemes, access control for a system you operate, ticketing where you also run the gates.
It is the wrong tool for impersonating a credential somebody else issued. Registering to handle an identifier does not give you the keys the real card holds, so the terminal will refuse the exchange even though your application answered.
And open host card emulation, available to any application, is Android only. Since iOS 17.4 Apple offers a gated equivalent through its NFC and SE Platform: an app granted Apple's entitlement, under a commercial agreement, can emulate cards, but only through that controlled route rather than an open one. Which route you have usually decides the design before anything else does.
Frequently asked questions
Does host card emulation need an internet connection?
The exchange with the reader does not, but implementations that use short lived tokens need connectivity to obtain them. Whether the phone works offline depends on how many tokens were fetched in advance rather than on the mechanism itself.
Is it less secure than a secure element?
It is differently secure. A secure element protects a permanent key in hardware, while this model limits the value of what can be extracted. For many uses the second is adequate and far easier to deploy.
Can I use it to emulate a MIFARE Classic card?
No. The mechanism handles the standard command exchange used by card applications, not proprietary schemes that operate below that layer. This is one of several reasons Classic based systems resist phone credentials.
Is there an iOS equivalent?
Not an equivalent open one. Apple offers a gated route since iOS 17.4, its NFC and SE Platform, available only to apps granted Apple's entitlement under a commercial agreement, not a general mechanism any app can use. A cross platform design cannot assume the open Android approach carries over.