The custom AT command "AT%XICCID" was added in modem firmware v1.1.3 for the nRF9160 and was available from the first release for the nRF91x1.
This command provides a processed (digits correctly ordered) and cached copy of the SIM's ICCID making it available even if the SIM is powered off (e.g. in CFUN=0 state).
However, there might be an issue with the cached copy when querying this command after changing the active UICC slot using the AT%CSUS command.
In my testing when I switched between a virtual UICC (AT%CSUS=2) to the physical SIM slot 1 (AT%CSUS=0), the reported ICCID (using %XICCID) was not updated until I powered the physical SIM again by entering a CFUN=1 or similar state. Perhaps the cached XICCID value should be invalidated, or updated, when a %CSUS operation switches between UICCs.
The second issue I have encountered is with trying to parse the output of the AT%XICCID command.
Specifically, it cannot be handled using the 'at_parser' library. Previously it was possible to use the 'at_param_list' library, but that was deprecated / removed from v2.8.0. The issue is that the 'at_parser' library will not allow for a token which starts with a numeric digit to be processed as a string, unless the token is wrapped in double quotes. Additionally, the numeric value of the ICCID is too large to fit in the largest INT64 type and so cannot be parsed as number. Right now, I have to treat parsing of this result as a special case using sscanf().
The 'at_parser' library could be modified to allow AT_TOKEN_TYPE_INT to be parsed as a string, however, this might introduce other issues.
Alternatively, the %XICCID output could wrap the result in double quotes. Perhaps for compatibility the command should take a parameter in a similar way that the AT+CGSN command does, i.e. AT%XICCID=1 would provide the result with the double quotes, allowing for backwards compatibility, resulting in:
AT%XICCID
%XICCID: 8901234567012345678F
OK
AT%XICCID=1
%XICCID: "8901234567012345678F"
OK