Software House CCOTZ 37-bit Explained (C•CURE / iSTAR)

Software House, C•CURE 9000 and iSTAR

Software House is the access-control division now operated under Johnson Controls (formerly Tyco Security Products). Its two flagship controller families—C•CURE 9000, an enterprise-grade software platform, and iSTAR, its dedicated hardware controller line—are widely deployed in corporate campuses, government facilities, healthcare systems and financial institutions across North America and internationally. Both platforms communicate credential data via the Wiegand protocol, reading bit patterns from cards and fobs presented at door readers.

Because the C•CURE and iSTAR product lines are built around a unified credential ecosystem, the readers are configured from the factory to expect the specific CCOTZ bit arrangement. Sites running these controllers cannot simply substitute off-the-shelf 37-bit cards and expect them to work. If a credential presents a standard HID 37-bit layout, the controller parses the fields incorrectly—facility code and card number collide with parity positions—and access is denied or the event is logged as an invalid read. Understanding this is the first step in managing a Wiegand bit-format card programme correctly.

Why CCOTZ Is Not Just ‘a 37-bit Card’

The Wiegand protocol specifies how many bits travel down the data line and in what voltage sequence, but it says nothing about how those bits are subdivided into fields. A 37-bit frame could be split in dozens of ways—different widths for the leading parity bit, the facility-code block, the card-number block, and the trailing parity bit. Each vendor-defined split creates a distinct, non-interchangeable format. The Complete Wiegand Format Guide covers this in detail, but the short version is that format names like “H10304” (HID’s 37-bit) and “CCOTZ” are shorthand for a specific, proprietary partitioning of those 37 bits.

CCOTZ is one of the formats Security ID Systems classifies in its high-security and custom-format range precisely because no compatible credentials for it have historically been available through general distributors. The field positions that Software House chose are not derived from any ANSI or SIA standard, and the precise layout is not published in any public datasheet. That is what makes it a Tier-S proprietary format and what makes sourcing replacements difficult without a specialist supplier who has documented the format from hardware samples.

The CCOTZ Field Layout Decoded

CCOTZ uses a 37-bit total frame structured as follows: 1 leading even-parity bit, a facility-code field (number of bits differs from H10304), a card-number field, and 1 trailing odd-parity bit. The precise bit widths for facility code and card number are inverted relative to H10304: where H10304 allocates a wider field to facility code and a narrower one to card number, CCOTZ allocates widths in the opposite proportion. The two parity bits each cover different halves of the payload, and the parity rules themselves apply to a different group of bits than they do in H10304. These are not cosmetic differences—they change which card numbers are representable and how many unique facility codes the system can address.

In practice, this means a site running C•CURE or iSTAR will typically see facility codes in a range and with a distribution that looks unfamiliar compared with HID-issued sites. The credential number space is structured to Software House’s internal assignment conventions. When ordering compatible credentials, you must supply your existing facility code exactly as programmed into the controller—not a code from a card’s printed number, which may or may not match the encoded value. Our guide to corporate and custom facility codes walks through how to confirm the programmed facility code before placing an order.

It is also worth noting that CCOTZ credentials have been issued on both 125 kHz proximity technology and on the HF legacy iCLASS platform. The underlying bit format is identical across both carrier frequencies; what changes is the radio layer and the chip technology used to store and transmit the data. A Software House CCOTZ 37-bit compatible card reproduced on a T5577 or EM4305 substrate operates at 125 kHz and is the standard replacement for the large majority of C•CURE and iSTAR sites still using proximity readers.

Encoding a Compatible CCOTZ Credential

Manufacturing a compatible CCOTZ credential starts with encoding the correct 37-bit payload onto the chosen substrate. The encoding process writes the facility code into its proper field position, writes the card number into its proper field, and computes both parity bits from the precise group of bits that CCOTZ specifies—not the groups used by H10304 or any other 37-bit variant. An encoder that treats all 37-bit formats as interchangeable will produce a card that fails at the reader. This is why CCOTZ cannot be ordered from most proximity card suppliers: they do not hold the documented field map and cannot produce a correctly parity-checked credential.

Security ID Systems also supplies a Software House CCOTZ 37-bit compatible card variant for sites using a 15-digit card-number range, in addition to the standard range. Whether you are provisioning credentials for a new employee, replacing a lost card, or expanding a site that has been running C•CURE for years, the encoding is handled to the same field specification—facility code and card number in the correct CCOTZ positions with correct parity. No configuration is needed at the controller; it reads the credential exactly as it would read an originally issued Software House card.

For comparably obscure custom formats on other access-control platforms, the same precision encoding approach applies. Formats such as the Lenel 42-bit compatible proximity card and the ATS Aritech 32-bit compatible proximity card each carry their own vendor-specific field maps, and each must be encoded to spec to function correctly with the originating controller. There is no universal “custom format” shortcut.

Ordering: Format, Facility Code and Verification

To order compatible CCOTZ credentials, you will need three pieces of information: confirmation that your site runs C•CURE 9000 or iSTAR (not a third-party controller that also accepts 37-bit data), your facility code as programmed in the controller, and the card-number range you need. If you have existing cards on site, our team can assist with verifying the encoded facility code against the printed or programmed value—this is particularly important on older sites where the original commissioning documentation may have been lost.

If your installation uses a more advanced credential layer—for instance, iCLASS SE or a multi-technology card—the same CCOTZ payload is enrolment-based on those platforms, meaning your controller and readers manage the secure application layer and enrol the credential during commissioning. Compatible blank credentials for those platforms, as discussed in our honest buyer’s guide to compatible vs genuine cards, are supplied as enrolable blanks; the CCOTZ data is written by your system during enrolment, not pre-encoded at manufacture. Our team will confirm which supply model applies to your specific reader and controller generation before any order is placed.

Sites with mixed-format environments—where some doors read CCOTZ and others use a different proprietary format—may benefit from reviewing the broader landscape of high-security custom formats available from Security ID Systems. Solutions such as HID Corporate 1000 compatible cards illustrate how similarly proprietary formats on other platforms are handled: same principle, different field map, same rigour in encoding.

Security ID Systems is an independent manufacturer and supplier of compatible access-control credentials and is not affiliated with, authorized by, or endorsed by Johnson Controls, Tyco Security Products, or Software House.