What microSD Card Should I Specify for Access Control and Door Terminals?

TL;DR

For access control and door terminals, specify a small-capacity, name-brand-controller microSD card with a file system your terminal firmware actually supports, and treat capacity as the least important variable.

Concretely, for most door and access terminals:

• Capacity band: 8 GB to 32 GB is the practical working range for event logging, user databases and firmware staging. Go to 64 GB or above only if the terminal stores images, video or long retention logs — and confirm the host supports SDXC/exFAT first.
• File system: FAT32 for anything that must be readable by the widest range of embedded hosts; exFAT only if the terminal firmware explicitly supports it; never assume a Linux-based terminal wants ext4 on a removable card unless the vendor says so.
• Card class: the speed class matters far less than power-loss behavior and controller compatibility. A card that the host fails to enumerate is worse than a slow one.
• What to lock in the BOM: controller family, capacity, file system, formatting procedure, lot traceability, and a documented incoming test.
• What to test before volume: enumeration on the actual terminal, power-cut during write, log rotation, and real capacity.

The rest of this guide walks through each of those decisions, then gives you a purchase-order checklist you can hand to a supplier.

Scope note: This article separates general industry standards and engineering practice from WINTEL’s confirmed capabilities. WINTEL-specific statements are limited to what is listed in the company facts below. Anything else is industry guidance, not a WINTEL claim.

---

Why access control is a different buying problem

Access control and door terminals sit in an awkward spot between consumer and industrial electronics:

• They are fixed, mains- or PoE-powered, and expected to run for years without anyone touching the card.
• They write very little most of the time — an event record when a door opens, a log line when a user is added — but they can write in bursts during firmware updates, bulk user imports, or video/face-template capture.
• They are often installed by an integrator, not the OEM, so the card may be swapped by a technician who grabs whatever is in the van.
• They are frequently Linux-based (many terminals run an embedded Linux build), which changes how the card is mounted and how it fails.

That combination means the failure modes that matter are not “is it fast enough” but:

1. Does the host enumerate the card at all? Some embedded hosts are picky about card initialization timing and certain controller families.
2. What happens on power loss mid-write? Door terminals get power-cycled by electricians, UPS failures and brownouts.
3. Is the capacity real? A counterfeit 64 GB card that is actually 8 GB will silently corrupt a user database.
4. Will the card still be readable in five years? Retention on unpowered flash is finite; a card that sits mostly idle still needs to be a known-good part.

None of those are solved by buying a faster card. They are solved by specifying the card correctly and testing it.

---

Capacity: which band actually fits

Capacity is usually the first thing buyers ask about and the last thing that should drive the decision. Here is how to think about it by terminal type.

Terminal role	Typical write pattern	Sensible capacity band	Notes
Door controller / reader with local event buffer	Small event records, periodic upload	8–16 GB	More than enough; the card is a buffer, not an archive
Access terminal with local user database and firmware staging	Occasional bulk writes	16–32 GB	Leave headroom for firmware images
Terminal with photo capture (visitor logs, snapshot on denied access)	Bursts of image files	32–64 GB	Confirm SDXC/exFAT support before going above 32 GB
Terminal with video intercom or face recognition	Continuous or burst video	64 GB+ or soldered storage	Strongly consider eMMC/UFS instead of a removable card

Two rules of thumb:

• Above 32 GB you cross from SDHC to SDXC, and the default file system changes with it. If the terminal firmware was written for FAT32 on an SDHC card, a 64 GB SDXC card may not mount at all. Check this before you buy capacity you cannot use. The SD Association’s capacity overview explains the SDHC/SDXC split.
• If the terminal writes video continuously, a removable card is usually the wrong architecture. Continuous video on a microSD card in a fixed device is a wear and thermal problem. A soldered eMMC or UFS part, or a card designed and rated for continuous recording, is the better engineering answer. JEDEC’s managed-NAND standards are the reference point for the soldered option.

Illustrative only — not WINTEL data: a terminal writing 200 bytes per event, 500 events per day, produces about 36 MB per year of event data. A 16 GB card would take centuries to fill at that rate — which is exactly why capacity is not the constraint for pure event logging. The constraint is whether the card survives power cuts and whether the host keeps mounting it.

---

File system: the decision that breaks more deployments than capacity

This is where most access control projects get into trouble. The card is fine; the file system is wrong for the host.

FAT32

• Readable by essentially every embedded host, RTOS and bootloader.
• 4 GB maximum single-file size and volume-size limits that vary by host. Microsoft documents the FAT32 file-size ceiling; it is a hard limit, not a tuning knob.
• The safe default when you do not know the host’s capabilities.

exFAT

• The default file system on SDXC cards (above 32 GB).
• No 4 GB file limit, better for large log or video files.
• Only use it if the terminal firmware explicitly supports it. Many older embedded Linux builds and RTOS file system layers do not. Microsoft publishes the exFAT specification if you need to check what the host must implement.

ext4 / other Linux file systems

• Some Linux-based terminals will happily mount ext4 on a removable card.
• This is a firmware decision, not a card decision. Do not format cards ext4 at the factory unless the terminal vendor has told you to. A card formatted ext4 will be unreadable on a Windows service laptop, which complicates field replacement.

What to actually specify

1. Ask the terminal vendor: what file system does your firmware expect on the removable card, and what is the maximum capacity it will mount?
2. Write the answer into the BOM as a hard requirement.
3. Specify that cards ship formatted to that file system, and that the terminal re-formats on first boot or commissioning as the authoritative step.

The Linux kernel MMC/SD documentation is a useful reference if you are debugging enumeration problems on a Linux-based terminal — it describes how the host controller and card interact, which is where “card not detected” issues usually live.

---

What the equipment will and will not accept

Before you choose a card, get these answers from the terminal vendor. If they cannot answer, that is itself a finding.

Host compatibility checklist (ask the terminal vendor):

• Maximum card capacity the firmware will mount (8 / 32 / 64 / 128 GB).
• File system expected on the card (FAT32 / exFAT / other).
• Whether the host supports SDHC only, or SDHC and SDXC.
• Known-good or known-bad card controller families, if any.
• Whether the firmware writes to the card continuously, on event, or only during updates.
• What the firmware does on write failure — retry, remount read-only, alarm, or ignore.
• Whether the card is hot-swappable in the field, and what the replacement procedure is.
• Whether the terminal can re-format the card from its own menu or API.

What the card will and will not accept (ask your card supplier):

• Controller family and whether it is a known part with published errata.
• Whether the card has power-fail protection or a documented behavior on sudden power loss.
• Real, tested capacity — not the marked capacity.
• Lot traceability: can the supplier tell you which die and controller went into which lot?
• Whether the supplier will supply a retained sample per lot.

If you are sourcing from a factory and want to understand how lot traceability and die marking work in practice, see flash memory lot traceability and die marking. If you are worried about capacity fraud specifically, fake USB drive capacity: how to check covers the testing method, and the same logic applies to cards.

---

What to lock in the BOM

A BOM line for a microSD card in an access terminal should be specific enough that a different supplier cannot quietly substitute a different part. At minimum, lock:

1. Form factor and capacity — e.g. microSDHC, 16 GB. State the class (SDHC vs SDXC) explicitly, not just the number.
2. Controller family — the actual controller part or family, not “high quality controller.”
3. Interface and speed class — the class the host requires, not the fastest class available.
4. File system and formatting state at delivery — FAT32, formatted, with the exact cluster size if the host is sensitive to it.
5. Operating behavior — power-loss behavior, and whether the card is rated for the terminal’s temperature environment. Do not assume; ask.
6. Marking and labeling — what is printed on the card, and whether the OEM’s part number appears.
7. Traceability — lot code, die marking, and retained sample per lot.
8. Incoming test — the exact test the OEM will run on receipt, and the accept/reject criteria.

If you are also specifying the enclosure or the terminal’s internal storage layout, flash footprint and enclosure design covers how the card slot and surrounding mechanicals interact with the rest of the design.

---

Purchase-order checklist for access control terminals

Use this as a template. It is written so you can paste it into an RFQ or attach it to a PO.

1. Scope and quantity

• Annual volume and first-order quantity.
• Delivery schedule and whether it is a one-time buy or a repeating release.
• Whether the supplier holds buffer stock, and for how long.

2. Technical specification

• Card type: microSDHC or microSDXC (state explicitly).
• Capacity in GB.
• Controller family (named).
• Speed class required by the host.
• File system at delivery, and cluster size if applicable.
• Power-loss behavior / protection requirement.
• Operating temperature range required by the terminal environment.
• Marking: OEM part number, lot code, date code.

3. Quality and traceability

• Lot traceability to die and controller.
• Retained sample per lot, held for an agreed period.
• Incoming inspection procedure and accept/reject criteria.
• Certificate of conformance content — see certificate of conformance: what it says for what to require.
• Handling of non-conforming lots: replacement, credit, or rework.

4. Testing before volume

• Sample quantity and sample fee — see flash sample fee and what to test on one.
• Enumeration test on the actual terminal model.
• Power-cut-during-write test.
• Log rotation and long-run test.
• Real capacity and sustained write test.
• Acceptance sign-off before the first production release.

5. Commercial and logistics

• Unit price and price validity period — see currency clauses: two places the price moves.
• Payment schedule and deposit — see how much deposit: payment schedules explained.
• Incoterms and who is importer of record — see DDP, importer of record and VAT recovery.
• Packaging: bulk, reel, or individually bagged for field replacement.
• Lead time and peak-season freight assumptions.

6. Change control

• Written notification before any controller, die or firmware change.
• Right to re-qualify after a change.
• Agreed remedy if an unannounced change is found.

That last section is the one buyers most often skip, and it is the one that causes the most expensive field failures. A card that passed qualification and then quietly changed controller is a different part.

---

How WINTEL fits, and what we will not claim for you

WINTEL (Shenzhen Wintel Digital Technology Limited) manufactures custom TF/microSD cards, USB flash drives, UDP modules and semi-finished boards for OEM/ODM buyers, and offers pre-loading and formatting as part of the order. Confirmed company facts relevant to this guide:

• Legal entity: Shenzhen Wintel Digital Technology Limited (深圳市微盛鑫数码科技有限公司), founded 2015; team active in the industry since 2006.
• Manufacturing: 5,000 m² facility, 200+ employees, monthly capacity of 500,000+ units.
• Certifications on file: SGS, RoHS, CE, FCC.
• Export markets: 50+ countries.
• Contact: Cathy, cathy@go-wintel.com, +86-132 2685 1179.

We are not stating speed classes, endurance ratings, temperature ranges, MOQ, lead times, test results or customer cases in this article, because those are order-specific and should be confirmed against your specification and a sample. If a supplier quotes you a speed class or endurance figure without a part number and a test method attached, ask for both.

For the general question of how long a custom microSD order takes, see how long does a custom microSD order take. For capacity planning, the TF card capacity estimator will help you sanity-check the numbers before you write them into a spec.

---

A note on sourcing and counterfeits

Access control buyers are exposed to counterfeit cards in a specific way: the card is often bought in bulk by a distributor or integrator, not by the OEM, and it is rarely inspected. Two practical controls:

1. Test capacity on a sample from every lot, not just the first. A capacity test that writes until failure and reads back is cheap and catches the most common fraud.
2. Retain a sample per lot so that if a field failure occurs you can compare the failed card against the lot it came from.

If you are buying from a Chinese factory for the first time, buying from a Chinese factory as a private individual covers the commercial side, and can you match this sample: reverse engineering explains what a supplier can and cannot match from a physical sample.

---

FAQ

Do I need a high-endurance or “industrial” card for an access control terminal? It depends on write volume, not on the product category. A door terminal that writes a few event records per day puts almost no wear on a card; a terminal that also stores video, face templates or continuous logs does. Ask the terminal vendor what the firmware actually writes, then size endurance to that. If the vendor cannot answer, treat it as a red flag and test on a sample before locking the BOM.

Can I just use the cheapest 32 GB card I can find? For low-write event logging, a small-capacity card is often the right technical choice, but “cheapest” is the wrong selection criterion. The failure modes that matter in a fixed terminal are power-loss corruption, counterfeit capacity and controller/firmware incompatibility — none of which show up on a price list. Specify the card by controller family, capacity, file system and power-loss behavior, then verify on a sample.

Should the card be pre-formatted by the factory? Yes, ask for it, but do not rely on it. Format the card in the terminal’s own firmware during commissioning, because that is the format the device will actually use. Factory formatting is useful mainly to confirm the card arrives healthy and to save a step on the line.

What happens to the card if the terminal loses power mid-write? It can corrupt the file system or the file being written. Cards with power-fail protection and file systems with journaling or atomic-rename behavior reduce the risk, but the real fix is firmware design: write to a temp file and rename, keep the log append-only, and mount read-only when not writing. Specify this with the terminal vendor, not only with the card supplier.

How do I protect against counterfeit or re-marked cards in a production run? Buy from a supplier who can show lot traceability and die marking, test capacity and real-world write speed on incoming samples, and keep a retained sample from each lot. Cheap cards with inflated capacity are a known problem; a capacity test on a sample from every lot is the cheapest insurance you can buy.

---

Sources

• SD Association — SD Specifications (Physical Layer, File System): https://www.sdcard.org/downloads/pls/ (accessed 2026-10-28)
• SD Association — Capacity overview (SDHC/SDXC): https://www.sdcard.org/developers/sd-standard-overview/capacity-sd-sdhc-sdxc-cards/ (accessed 2026-10-28)
• Microsoft Learn — exFAT file system specification: https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification (accessed 2026-10-28)
• Microsoft Learn — Maximum file size (FAT32 limits): https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-size (accessed 2026-10-28)
• Linux kernel documentation — MMC/SD subsystem: https://docs.kernel.org/driver-api/mmc/index.html (accessed 2026-10-28)
• JEDEC — Standards and documents (managed NAND / eMMC): https://www.jedec.org/standards-documents (accessed 2026-10-28)

---

Need a quote against this checklist? Send your terminal model, capacity band, file system and volume to Cathy at cathy@go-wintel.com, or use the RFQ form. We will confirm what we can supply and what needs a sample before we commit to a specification.