Many people are surprised to learn that EMV doesn't encrypt the PAN. But really, once EMV is fully rolled out encrypting the PAN will become unnecessary, and would be leftover as a technical debt of the current insecure protocols. EMV doesn't need to start with that baggage.
The reason EMV doesn't require encryption of the PAN is that the PAN only represents Identity; it does not represent Authentication of the chip (that's the job of the ARQC message), and it does not represent the Authorization of the cardholder to use the card (that's the job of the PIN). As long as the chip is authenticated, and the user provides the authorization, the transaction is secured. The identity doesn't have to be kept secret.
In today's non-EMV world, identity, authentication, and authorization are all three combined on the unchanging mag stripe. Copying the stripe data enables you to clone a card, so protecting the whole stripe is required. We use the words "identity theft" so people think they're stealing our identity, but really, they're stealing all three attributes from the card at the same time.
With EMV, the PAN is still required to provide the identity of the card. The rest of the EMV data does not include enough information to otherwise identify the card, nor should it. The identity can even be made public, as long as it can't be used by itself.
In EMV, the ARQC cryptogram serves as the signature from the chip, authenticating the messages originated from the chip associated with the PAN. Cryptography and secure storage on the chips ensure that an ARQC can't be forged. Because the ARQC is transactional, every request is different; replay attacks don't work as long as the bank ensures duplicate ARQCs are rejected.
The PIN serves as the user's authorization to charge. The PIN tells the chip "hey, your user just proved right now that he wants this transaction to go through." It's up to your bank if they want your card to require a PIN; they might be happy just letting you sign for the transaction.
[ Note that most U.S. banks opted for Chip and Signature instead of Chip and PIN. The only advantage of Chip and PIN is that it protects your card from unauthorized use if it's lost or stolen; but really, the FDIC already limits your personal liability to $50, and almost all banks waive that to $0 in the case of a lost or stolen card. And since the banks make money every time you charge anything, they'd rather accept the risk of fraud (that they're already obliged to take by law) than to inconvenience their customers by making them type a PIN. They believe that inconvenienced customers will find an easier way to pay, cutting into their profits.]
But we're a long ways away from full EMV rollout. The October 2015 liability shift was created as incentive for U.S. retailers to change their transaction processing to use EMV, but very few U.S. retailers actually take chip cards as of April 2016. Rolling out new terminals, new software, and new cards across 6 million retailers, 11,000 banks, and billions of cards takes a lot of time and money. And nobody's yet created a universally accepted solution to secure Card Not Present (CNP) transactions, such as hotel bookings, web purchases, etc. So until EMV is fully deployed and the CNP problem solved, it's still up to merchants and POS terminals to protect and encrypt the PANs and the sensitive authorization data. For now, that includes the PAN.
